From: David Miller <davem@davemloft.net>
To: npiggin@suse.de
Cc: benh@kernel.crashing.org, jeremy@goop.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, hugh@veritas.com
Subject: Re: PTE access rules & abstraction
Date: Mon, 22 Sep 2008 20:16:10 -0700 (PDT) [thread overview]
Message-ID: <20080922.201610.246167553.davem@davemloft.net> (raw)
In-Reply-To: <20080923031037.GA11907@wotan.suse.de>
From: Nick Piggin <npiggin@suse.de>
Date: Tue, 23 Sep 2008 05:10:37 +0200
> Part of the problem with the pte API (as well as the cache flush and
> tlb flush APIs) is that it often involves the core mm code telling
> the arch how it thinks ptes,tlbs,caches should be managed, rather than
> I think the better approach would be telling the arch what it wants to
> do.
>
> We are getting better slowly I think (eg. you note that set_pte_at is
> no longer used as a generic "do anything"), but I won't dispute that
> this whole area could use an overhaul; a document for all the rules,
> a single person or point of responsibility for those rules...
I agree.
To a certain extent this is what BSD does in it's pmap layer, except
that they don't have the page table datastructure abstraction like
Linus does in the generic code, and which I think was a smart design
decision on our side.
All of the pmap modules in BSD are pretty big and duplicate a lot of
code that arch's don't have to be mindful about under Linux.
WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
From: Nick Piggin <npiggin@suse.de>
To: npiggin@suse.de
Cc: benh@kernel.crashing.org, jeremy@goop.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, hugh@veritas.com
Subject: Re: PTE access rules & abstraction
Date: Mon, 22 Sep 2008 20:16:10 -0700 (PDT)
Date: Tue, 23 Sep 2008 05:10:37 +0200 [thread overview]
Message-ID: <20080922.201610.246167553.davem@davemloft.net> (raw)
In-Reply-To: <20080923031037.GA11907@wotan.suse.de>
> Part of the problem with the pte API (as well as the cache flush and
> tlb flush APIs) is that it often involves the core mm code telling
> the arch how it thinks ptes,tlbs,caches should be managed, rather than
> I think the better approach would be telling the arch what it wants to
> do.
>
> We are getting better slowly I think (eg. you note that set_pte_at is
> no longer used as a generic "do anything"), but I won't dispute that
> this whole area could use an overhaul; a document for all the rules,
> a single person or point of responsibility for those rules...
I agree.
To a certain extent this is what BSD does in it's pmap layer, except
that they don't have the page table datastructure abstraction like
Linus does in the generic code, and which I think was a smart design
decision on our side.
All of the pmap modules in BSD are pretty big and duplicate a lot of
code that arch's don't have to be mindful about under Linux.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-09-23 3:16 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-19 17:42 PTE access rules & abstraction Benjamin Herrenschmidt
2008-09-19 17:42 ` Benjamin Herrenschmidt
2008-09-22 6:22 ` Jeremy Fitzhardinge
2008-09-22 6:22 ` Jeremy Fitzhardinge
2008-09-22 21:05 ` Benjamin Herrenschmidt
2008-09-22 21:05 ` Benjamin Herrenschmidt
2008-09-23 3:10 ` Nick Piggin
2008-09-23 3:10 ` Nick Piggin
2008-09-23 3:16 ` David Miller [this message]
2008-09-23 3:16 ` David Miller, Nick Piggin
2008-09-23 5:35 ` Benjamin Herrenschmidt
2008-09-23 5:35 ` Benjamin Herrenschmidt
2008-09-23 6:18 ` Nick Piggin
2008-09-23 6:18 ` Nick Piggin
2008-09-23 5:31 ` Benjamin Herrenschmidt
2008-09-23 5:31 ` Benjamin Herrenschmidt
2008-09-23 6:13 ` Jeremy Fitzhardinge
2008-09-23 6:13 ` Jeremy Fitzhardinge
2008-09-23 6:49 ` Benjamin Herrenschmidt
2008-09-23 6:49 ` Benjamin Herrenschmidt
2008-09-23 9:50 ` Nick Piggin
2008-09-23 9:50 ` Nick Piggin
2008-09-23 11:54 ` peter
2008-09-23 11:54 ` peter
2008-09-24 18:45 ` Hugh Dickins
2008-09-24 18:45 ` Hugh Dickins
2008-09-24 21:20 ` Benjamin Herrenschmidt
2008-09-24 21:20 ` Benjamin Herrenschmidt
2008-09-24 21:57 ` Jeremy Fitzhardinge
2008-09-24 21:57 ` Jeremy Fitzhardinge
2008-09-24 22:07 ` Benjamin Herrenschmidt
2008-09-24 22:07 ` Benjamin Herrenschmidt
2008-09-24 22:43 ` Jeremy Fitzhardinge
2008-09-24 22:43 ` Jeremy Fitzhardinge
2008-09-24 22:53 ` Benjamin Herrenschmidt
2008-09-24 22:53 ` Benjamin Herrenschmidt
2008-09-24 23:55 ` Hugh Dickins
2008-09-24 23:55 ` Hugh Dickins
2008-09-25 1:04 ` Benjamin Herrenschmidt
2008-09-25 1:04 ` Benjamin Herrenschmidt
2008-09-25 18:15 ` Jeremy Fitzhardinge
2008-09-25 18:15 ` Jeremy Fitzhardinge
2008-09-25 21:44 ` Benjamin Herrenschmidt
2008-09-25 21:44 ` Benjamin Herrenschmidt
2008-09-25 22:27 ` Jeremy Fitzhardinge
2008-09-25 22:27 ` Jeremy Fitzhardinge
2008-09-25 23:02 ` Benjamin Herrenschmidt
2008-09-25 23:02 ` Benjamin Herrenschmidt
2008-09-24 22:17 ` Martin Schwidefsky
2008-09-24 22:17 ` Martin Schwidefsky
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=20080922.201610.246167553.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=benh@kernel.crashing.org \
--cc=hugh@veritas.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.