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, 17 May 2011 15:26:17 +0900 From: Minchan Kim <minchan.kim@...il.com> To: Wu Fengguang <fengguang.wu@...el.com> Cc: Andi Kleen <andi@...stfloor.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Andrew Lutomirski <luto@....edu>, LKML <linux-kernel@...r.kernel.org> Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux) On Tue, May 17, 2011 at 2:52 PM, Wu Fengguang <fengguang.wu@...el.com> wrote: > On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote: >> On Mon, May 16, 2011 at 12:27 AM, Wu Fengguang <fengguang.wu@...el.com> wrote: >> > On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote: >> >> On Sun, May 15, 2011 at 2:43 AM, Andi Kleen <andi@...stfloor.org> wrote: >> >> > Copying back linux-mm. >> >> > >> >> >> Recently, we added following patch. >> >> >> https://lkml.org/lkml/2011/4/26/129 >> >> >> If it's a culprit, the patch should solve the problem. >> >> > >> >> > It would be probably better to not do the allocations at all under >> >> > memory pressure. Even if the RA allocation doesn't go into reclaim >> >> >> >> Fair enough. >> >> I think we can do it easily now. >> >> If page_cache_alloc_readahead(ie, GFP_NORETRY) is fail, we can adjust >> >> RA window size or turn off a while. The point is that we can use the >> >> fail of __do_page_cache_readahead as sign of memory pressure. >> >> Wu, What do you think? >> > >> > No, disabling readahead can hardly help. >> >> I don't mean we have to disable RA. >> As I said, the point is that we can use __GFP_NORETRY alloc fail as >> _sign_ of memory pressure. > > I see. > >> > >> > The sequential readahead memory consumption can be estimated by >> > >> > 2 * (number of concurrent read streams) * (readahead window size) >> > >> > And you can double that when there are two level of readaheads. >> > >> > Since there are hardly any concurrent read streams in Andy's case, >> > the readahead memory consumption will be ignorable. >> > >> > Typically readahead thrashing will happen long before excessive >> > GFP_NORETRY failures, so the reasonable solutions are to >> >> If it is, RA thrashing could be better sign than failure of __GFP_NORETRY. >> If we can do it easily, I don't object it. :) > > Yeah, the RA thrashing is much better sign because it not only happens > long before normal __GFP_NORETRY failures, but also offers hint on how > tight memory pressure it is. We can then shrink the readahead window > adaptively to the available page cache memory :) > >> > >> > - shrink readahead window on readahead thrashing >> > (current readahead heuristic can somehow do this, and I have patches >> > to further improve it) >> >> Good to hear. :) >> I don't want RA steals high order page in memory pressure. > > More often than not it won't be RA's fault :) When you see RA page > allocations stealing high order pages, it may actually be reflecting > some more general order-0 steal order-N problem.. Agree. As I said to Andy, it's a general problem but RA has a possibility to reduce it while others don't have a any solution. :( -- Kind regards, Minchan Kim -- 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