public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Hugh Dickins <hugh@veritas.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] rmap: parisc __flush_dcache_page
Date: 08 Apr 2004 13:49:55 -0500	[thread overview]
Message-ID: <1081450196.1885.492.camel@mulgrave> (raw)
In-Reply-To: <20040408184245.GO31667@dualathlon.random>

On Thu, 2004-04-08 at 13:42, Andrea Arcangeli wrote:
> What you miss is that the problem is not in flush_dcache_page, the
> problem is that the _other_ users of the prio-tree may take as long as a
> timeslice. So it's the _other_ user that you've no control about (i.e.
> truncate) that may take timeslices with irq disabled.

So the problem isn't in the parisc code, it's in the generic vm code,
OK.

> But I've an fairly optimal solution for you, you should make it a
> read_write spinlock, with the readers not disabling interrupts, and the
> writer disabling interrupts, the writer of the prio-tree will not take a
> timeslice, the readers instead will take a timeslice, but since they're
> readers and you've only to read in the flush_dcache_page irq context,
> you don't need to disable irqs for the readers.  I don't have better
> solutions than this one at the moment (yeah there's the rcu reading of
> the prio-tree but I'd leave it for later...)

Yes, I'll go for that.  The write need only be done on vma insert, which
should be very fast.  So do we agree this is a generic solution, or were
you still thinking of trying to abstract it per-arch?

James



  reply	other threads:[~2004-04-08 18:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-08 13:41 rmap: parisc __flush_dcache_page Hugh Dickins
2004-04-08 13:52 ` [parisc-linux] " James Bottomley
2004-04-08 14:16   ` Hugh Dickins
2004-04-08 14:40     ` James Bottomley
2004-04-08 15:14       ` Andrea Arcangeli
2004-04-08 15:28         ` James Bottomley
2004-04-08 15:34           ` Andrea Arcangeli
2004-04-08 15:47             ` James Bottomley
2004-04-08 16:16               ` Andrea Arcangeli
2004-04-08 16:29                 ` James Bottomley
2004-04-08 17:10                   ` Andrea Arcangeli
2004-04-08 17:43                     ` James Bottomley
2004-04-08 17:51                       ` Andrea Arcangeli
2004-04-08 18:07                         ` James Bottomley
2004-04-08 18:18                           ` Andrea Arcangeli
2004-04-08 18:28                             ` James Bottomley
2004-04-08 18:42                               ` Andrea Arcangeli
2004-04-08 18:49                                 ` James Bottomley [this message]
2004-04-08 19:02                                   ` Andrea Arcangeli
2004-04-10  1:21                                 ` Paul E. McKenney
2004-04-08 15:35         ` Hugh Dickins
2004-04-08 16:13           ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1081450196.1885.492.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=andrea@suse.de \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parisc-linux@parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox