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
| ||
|
Message-ID: <alpine.DEB.2.00.1202091345540.4413@router.home> Date: Thu, 9 Feb 2012 13:53:58 -0600 (CST) From: Christoph Lameter <cl@...ux.com> To: Mel Gorman <mgorman@...e.de> cc: Andrew Morton <akpm@...ux-foundation.org>, Linux-MM <linux-mm@...ck.org>, Linux-Netdev <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, David Miller <davem@...emloft.net>, Neil Brown <neilb@...e.de>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Pekka Enberg <penberg@...helsinki.fi> Subject: Re: [PATCH 02/15] mm: sl[au]b: Add knowledge of PFMEMALLOC reserve pages On Thu, 9 Feb 2012, Mel Gorman wrote: > Ok, I am working on a solution that does not affect any of the existing > slab structures. Between that and the fact we check if there are any > memalloc_socks after patch 12, the impact for normal systems is an additional > branch in ac_get_obj() and ac_put_obj() That sounds good in particular since some other things came up again, sigh. Have not had time to see if an alternate approach works. > > We have been down this road too many times. Logic is added to critical > > paths and memory structures grow. This is not free. And for NBD swap > > support? Pretty exotic use case. > > > > NFS support is the real target. NBD is the logical starting point and > NFS needs the same support. But this is already a pretty strange use case on multiple levels. Swap is really detrimental to performance. Its a kind of emergency outlet that gets worse with every new step that increases the differential in performance between disk and memory. On top of that you want to add special code in various subsystems to also do that over the network. Sigh. I think we agreed a while back that we want to limit the amount of I/O triggered from reclaim paths? AFAICT many filesystems do not support writeout from reclaim anymore because of all the issues that arise at that level. We have numerous other mechanisms that can compress swap etc and provide ways to work around the problem without I/O which has always be troublesome and these fixes are likely only to work in a very limited way causing a lot of maintenance effort because (given the exotic nature) it is highly likely that there are cornercases that only will be triggered in rare cases. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists