| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Aug 2008 10:26:01 -0500 From: Christoph Lameter <cl@...ux-foundation.org> To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> CC: LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>, tokunaga.keiich@...fujitsu.com Subject: Re: [RFC][PATCH 0/2] Quicklist is slighly problematic. KOSAKI Motohiro wrote: > So, if possible, I'd like to make short term solution. > I believe nobody oppose quicklist reducing. it is defenitly too fat. Correct. >> Good fixup but I would think that some more radical rework is needed. >> Maybe some of this needs to vanish into the TLB handling logic? > > What do you think wrong TLB handing? > pure performance issue? The generic TLB code could be made to do allow the allocation, the batching and freeing of the pages. Would remove the need for quicklists for some uses. > > Do you have any page allocator enhancement plan? > Can I help it? A simple approach would be to use the queueing method used in quicklists in the page allocator hotpath. But the devil is in the details .... There are numerous checks for the type of page that are done by the page allocator and not for the quicklists. Somehow we need to work around these. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists