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: Tue, 08 Apr 2008 23:40:07 +0200 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Pekka Enberg <penberg@...helsinki.fi> Cc: Christoph Lameter <clameter@....com>, Linus Torvalds <torvalds@...ux-foundation.org>, Hugh Dickins <hugh@...itas.com>, James Bottomley <James.Bottomley@...senPartnership.com>, Andrew Morton <akpm@...ux-foundation.org>, FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>, Jens Axboe <jens.axboe@...cle.com>, "Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] scsi: fix sense_slab/bio swapping livelock On Wed, 2008-04-09 at 00:11 +0300, Pekka Enberg wrote: > Christoph Lameter wrote: > > Hmmmm... Peter has the most experience with these issues. Maybe the best > > would be to have this sort of logic in a more general way in the page > > allocator? Similar issues surely exist with the page allocator and a fix > > there would fix it for all users. > > This needs some support in the slab allocator anyway. Keep in mind that > the patch is specifically addressing writeback in OOM conditions so we > must (1) prioritize GFP_TEMPORARY allocations over everyone else (which > just get NULL) and (2) use the remaining available memory as efficiently > as possible for _all_ GFP_TEMPORARY allocations. > > Peter is, however, bringing up a good point that my patch doesn't > actually _guarantee_ anything so I'm still wondering if this approach > makes any sense... But I sure do like Linus' ideas of marking > short-lived allocations and trying harder for them in OOM. Also, this scheme so far does not provide for a means to detect the end of pressure situation. I need both triggers, enter pressure and exit pressure. Enter pressure is easy enough, that's when normal allocations start failing. Exit pressure however is more difficult - that is basically when allocations start succeeding again. You'll see that my patches basically always attempt a regular allocation as long as we're in the emergency state. Also, the requirement for usage of emergency memory (GFP_MEMALLOC, PF_MEMALLOC) is that it will be freed without external conditions. So while it might be delayed for a while (it might sit in the fragment assembly cache for a while) it doesn't need any external input to get freed again: - it will either get reclaimed from this cache; - it will exit the cache as a full packet and: - get dropped, or - get processed. -- 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