From: Hugh Dickins <hughd@google.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH 2/3] track numbers of pagetable pages
Date: Tue, 26 Apr 2011 12:26:09 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.00.1104261217430.9334@sister.anvils> (raw)
In-Reply-To: <20110426155743.2e76282d@mfleming-mobl1.ger.corp.intel.com>
On Tue, 26 Apr 2011, Matt Fleming wrote:
> [Added Hugh Dickins to the CC list]
>
> Sorry it's taken me so long to reply Dave.
>
> On Mon, 18 Apr 2011 08:02:04 -0700
> Dave Hansen <dave@linux.vnet.ibm.com> wrote:
>
> > On Sat, 2011-04-16 at 10:44 +0100, Matt Fleming wrote:
> > > > static inline void pgtable_page_dtor(struct mm_struct *mm, struct page *page)
> > > > {
> > > > pte_lock_deinit(page);
> > > > + dec_mm_counter(mm, MM_PTEPAGES);
> > > > dec_zone_page_state(page, NR_PAGETABLE);
> > > > }
> > >
> > > I'm probably missing something really obvious but...
> > >
> > > Is this safe in the non-USE_SPLIT_PTLOCKS case? If we're not using
> > > split-ptlocks then inc/dec_mm_counter() are only safe when done under
> > > mm->page_table_lock, right? But it looks to me like we can end up doing,
> > >
> > > __pte_alloc()
> > > pte_alloc_one()
> > > pgtable_page_ctor()
> > >
> > > before acquiring mm->page_table_lock in __pte_alloc().
> >
> > No, it's probably not safe. We'll have to come up with something a bit
> > different in that case. Either that, or just kill the non-atomic case.
> > Surely there's some percpu magic counter somewhere in the kernel that is
> > optimized for fast (unlocked?) updates and rare, slow reads.
>
> It seems it was Hugh that added these atomics in f412ac08c986 ("[PATCH]
> mm: fix rss and mmlist locking").
>
> Hugh, what was the reason that you left the old counters around (the
> ones protected by page_table_lock)? It seems to me that we could
> delete those and just have the single case that uses the atomic_t
> operations.
The only reason was to avoid adding costly atomic operations into a
configuration that had no need for them there: the page_table_lock
sufficed.
Certainly it would be simpler just to delete the non-atomic variant.
And I think it's fair to say that any configuration on which we're
measuring performance to that degree (rather than "does it boot fast?"
type measurements), would already be going the split ptlocks route.
>
> Would anyone object to a patch that removed the non-atomic case?
Not I.
Hugh
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-04-26 19:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 17:38 [RFC][PATCH 0/3] track pte pages and use in OOM score Dave Hansen
2011-04-15 17:38 ` [RFC][PATCH 1/3] pass mm in to pgtable ctor/dtor Dave Hansen
2011-04-15 17:38 ` [RFC][PATCH 2/3] track numbers of pagetable pages Dave Hansen
2011-04-16 9:44 ` Matt Fleming
2011-04-18 15:02 ` Dave Hansen
2011-04-26 14:57 ` Matt Fleming
2011-04-26 19:26 ` Hugh Dickins [this message]
2011-04-15 17:38 ` [RFC][PATCH 3/3] use pte pages in OOM score Dave Hansen
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=alpine.LSU.2.00.1104261217430.9334@sister.anvils \
--to=hughd@google.com \
--cc=dave@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matt@console-pimps.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