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: Sat, 18 Aug 2007 07:10:36 +0000 From: Pavel Machek <pavel@....cz> To: Christoph Lameter <clameter@....com> Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, dkegel@...gle.com, Peter Zijlstra <a.p.zijlstra@...llo.nl>, David Miller <davem@...emloft.net>, Nick Piggin <npiggin@...e.de> Subject: Re: [RFC 2/9] Use NOMEMALLOC reclaim to allow reclaim if PF_MEMALLOC is set Hi! > If we exhaust the reserves in the page allocator when PF_MEMALLOC is set > then no longer give up but call into reclaim with PF_MEMALLOC set. > > This is in essence a recursive call back into page reclaim with another > page flag (__GFP_NOMEMALLOC) set. The recursion is bounded since potential > allocations with __PF_NOMEMALLOC set will not enter that branch again. > > This means that allocation under PF_MEMALLOC will no longer run out of > memory. Allocations under PF_MEMALLOC will do a limited form of reclaim > instead. > > The reclaim is of particular important to stacked filesystems that may > do a lot of allocations in the write path. Reclaim will be working > as long as there are clean file backed pages to reclaim. I don't get it. Lets say that we have stacked filesystem that needs it. That filesystem is broken today. Now you give it second chance by reclaiming clean pages, but there are no guarantees that we have any.... so that filesystem is still broken with your patch...? Should we fix the filesystem instead? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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