LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <firstname.lastname@example.org> To: Hugh Dickins <email@example.com> Cc: Andi Kleen <firstname.lastname@example.org>, Christoph Lameter <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, KOSAKI Motohiro <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, LKML <firstname.lastname@example.org>, Linus Torvalds <email@example.com>, Bart Van Assche <firstname.lastname@example.org> Subject: Re: quicklists confuse meminfo Date: Mon, 10 Mar 2008 10:31:02 -0700 [thread overview] Message-ID: <47D57056.email@example.com> (raw) In-Reply-To: <Pine.LNX.firstname.lastname@example.org> Hugh Dickins wrote: > On Mon, 10 Mar 2008, Andi Kleen wrote: > >> Christoph Lameter <email@example.com> writes: >> >>> Zeroed pages however will not address the issue of having initialized pgd >>> (which seems to be what i386 needs). >>> >> pgd is tiny on i386 PAE (4 * 16 bytes). Are you sure reinitializing that >> is a serious issue? ... >> > > It used to be tiny (32 aligned bytes), then 2.6.22's quicklist enlarged > that to a whole (lowmem) page. I think we were all too busy with other > stuff to protest loudly enough about that bloat. > Yes, I was surprised about the pgd page allocation. It's currently necessary for Xen (but I think I can fix that easily enough). But I was especially surprised it was imposed for everyone. > If the quicklists are going, it'd be good for PAE to go back to a > kmem_cache of 32-byte entries as in 2.6.21 - I think Ingo's patch is > still using a whole page there. > +1. We'd still need to maintain a list to link all the pgds together, but I think we can just allocate that out of the cache too (either the same object or a separate pgd list cache). > Or have sl?b alignment changes, or virtualization issues (locking > per underlying struct page?), made a kmem_cache awkward there now? > I think only Xen has a constraint. At the moment we rely on page-sized pgds for two things: 1. Xen marks the whole page as being of pgd-type, and so it can't have non-pgd contents (as the page would be RO, and any contents would be validated as pgd entries). However I can fix that by maintaining a separate per-cpu pgd page, and just copy the four entries over when cr3 is reloaded. This would move the Xen-specific requirements into the Xen code without affecting the rest of the kernel. 2. We still need to maintain a list of pgds, as I discussed above. So from my perspective there are no insoluble problems, and I'd fully support the transition. I've been working on unifying the pgalloc stuff, and the quicklist (i386) vs non-quicklist (x86-64) use has been a bit of a thorn in my side. Of course there'll still be the page-sized pgd vs non-page-sized pgd, but we just have to live with that. J
next prev parent reply other threads:[~2008-03-10 17:32 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-03-09 10:19 quicklists confuse meminfo Thomas Gleixner 2008-03-09 10:26 ` Bart Van Assche 2008-03-09 10:29 ` Andi Kleen 2008-03-09 10:42 ` KOSAKI Motohiro 2008-03-09 12:00 ` Thomas Gleixner 2008-03-09 11:14 ` Ingo Molnar 2008-03-09 11:56 ` Thomas Gleixner 2008-03-09 12:01 ` Ingo Molnar 2008-03-09 12:49 ` Andi Kleen 2008-03-10 15:51 ` Christoph Lameter 2008-03-09 12:03 ` Johannes Weiner 2008-03-09 12:03 ` KOSAKI Motohiro 2008-03-09 12:09 ` Ingo Molnar 2008-03-09 12:34 ` Ingo Molnar 2008-03-09 12:51 ` KOSAKI Motohiro 2008-03-09 13:20 ` Thomas Gleixner 2008-03-09 18:46 ` Andrew Morton 2008-03-09 20:21 ` Andi Kleen 2008-03-10 15:54 ` Christoph Lameter 2008-03-10 16:43 ` Andi Kleen 2008-03-10 17:19 ` Hugh Dickins 2008-03-10 17:25 ` Andi Kleen 2008-03-10 17:31 ` Jeremy Fitzhardinge [this message] 2008-03-10 17:53 ` Andi Kleen 2008-03-10 18:35 ` Jeremy Fitzhardinge 2008-03-10 19:06 ` Andi Kleen 2008-03-10 20:54 ` H. Peter Anvin 2008-03-10 21:26 ` Jeremy Fitzhardinge 2008-03-11 4:07 ` Nick Piggin 2008-03-21 12:52 ` Bart Van Assche 2008-03-21 14:45 ` Ingo Molnar 2008-03-26 7:45 ` Bart Van Assche 2008-03-26 7:53 ` Andrew Morton 2008-03-26 8:13 ` Ingo Molnar 2008-03-26 10:37 ` Bart Van Assche 2008-03-26 16:34 ` Christoph Lameter 2008-03-27 9:48 ` Bart Van Assche 2008-03-09 19:11 ` Arjan van de Ven 2008-03-09 19:25 ` Ingo Molnar 2008-03-09 19:27 ` Ingo Molnar 2008-03-09 19:31 ` Ingo Molnar 2008-03-10 15:57 ` Christoph Lameter 2008-03-10 15:55 ` Christoph Lameter 2008-03-09 12:47 ` KOSAKI Motohiro
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=47D57056.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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: linkBe 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; as well as URLs for NNTP newsgroup(s).