On Thu, 2018-07-12 at 11:06 -0700, Linus Torvalds wrote: > On Thu, Jul 12, 2018 at 10:21 AM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote: > > > > > > I don't know that it does work. Or that it works well. > > > > I'm not claiming the general heuristics are perfect (in fact I know > > we > > still have a lot of problems with dirty reclaim and writeback). > > I think this whole "this is about running out of memory" approach is > wrong. > > We *should* handle that well. Or well enough in practice, at least. > > Do we? Maybe not. Should the dcache be the one area to be policed and > worked around? Probably not. > > But there may be other reasons to just limit negative dentries. > > What does the attached program do to people? It's written to be > intentionally annoying to the dcache. So it's interesting. What happens for me is that I start out at pretty much no free memory so the programme slowly starts to fill up my available swap without shrinking my page cache (presumably it's causing dirty anonymous objects to be pushed out) and the dcache grows a bit. Then when my free swap reaches 0 we start to reclaim the dcache and it shrinks again (apparently still keeping the page cache at around 1.8G). The system seems perfectly usable while this is running (tried browser and a couple of compiles) ... any calls for free memory seem to come out of the enormous but easily reclaimable dcache. The swap effect is unexpected, but everything else seems to be going according to how I would wish. When I kill the programme I get about a megabyte of swap back but it's staying with the rest of swap occupied. When all this started I had an 8G laptop with 2G of swap of which 1G was used. Now I have 2G of swap used but it all seems to be running OK. So what I mean by dcache grows a bit is this: I missed checking it before I started, but it eventually grew to jejb@jarvis:~> cat /proc/sys/fs/dentry-state 2841534 2816297 45 0 0 0 Before eventually going back after I killed the programme to jejb@jarvis:~> cat /proc/sys/fs/dentry-state 806559 781138 45 0 0 0 I just tried it again and this time the dcache only peaked at jejb@jarvis:~> cat /proc/sys/fs/dentry-state 2321933 2296607 45 0 0 0 What surprises me most about this behaviour is the steadiness of the page cache ... I would have thought we'd have shrunk it somewhat given the intense call on the dcache. James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
