mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: lockdep: how to tell it multiple pte locks is OK?
Date: Sun, 7 Oct 2007 10:46:58 -0700	[thread overview]
Message-ID: <20071007104658.655565e3@laptopd505.fenrus.org> (raw)
In-Reply-To: <C2543D65-1241-47E6-8C06-BF6E4F73E19A@goop.org>

On Sun, 7 Oct 2007 10:17:47 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> 
> On Oct 7, 2007, at 9:58 AM, Arjan van de Ven wrote:
> 
> > On Sat, 06 Oct 2007 23:31:33 -0700
> >
> >> I'm presume I'm the first person to try holding multiple pte locks
> >> at once, so there's no existing locking order for these locks.  I'm
> >> always traversing and locking the pagetable in virtual address
> >> order (and this seems like a sane-enough rule for anyone else who
> >> wants to hold multiple pte locks).
> >
> > I'm not sure that's a valid assumption in light of things like
> > sharing pagetables between processes etc etc..
> > (granted, that one is out of tree right now but I still hope it'll
> > go in some day:)
> 
> Well, yes, but that will take some thought about how split pte locks  
> will work anyway (or more specifically, fork will probably just end  
> up reusing the pte pages and avoid the need to do any
> cross-pagetable pte locking anyway, though I guess that will be
> deferred to COW handling).
> 
> So are you saying I should pass up the opportunity to optimise a  
> relatively hot path (fork/exec/exit) because it will need some  
> further thought if/when shared ptes get implemented? 

s/implemented/merged/ :)

IN fact shared pagetables are already there for hugepages.
For small pages it's a patch at this point.

> Doesn't seem  
> like a good tradeoff...

no I'm not saying that. I'm just saying that I'm worried about the
locking robustness of your trick in general.

  reply	other threads:[~2007-10-07 17:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-07  6:31 Jeremy Fitzhardinge
2007-10-07  8:29 ` Peter Zijlstra
2007-10-07 15:06   ` Jeremy Fitzhardinge
2007-10-07 16:58 ` Arjan van de Ven
2007-10-07 17:17   ` Jeremy Fitzhardinge
2007-10-07 17:46     ` Arjan van de Ven [this message]
2007-10-09  0:20       ` Jeremy Fitzhardinge

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=20071007104658.655565e3@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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

all inboxes | Powered by JetHome®