Thanks Patrick for getting the ball rolling!
>1/ w.r.t drop_caches, "2" is *not* "inode and dentry". The '2' bit
> causes all registered shrinkers to be run, until they report there is
> nothing left that can be discarded. If this is taking 10 minutes,
> then it seems likely that some
Jacek,
“Accounting looks better when Lustre is not involved ;) Seriosly, how
can i help? Should i raise a bug? Try to provide a patch?”
A patch is always welcome.
We require a bug in our JIRA (jira.whamcloud.com) to submit a patch against.
(See here for instructions for our Gerrit:
1. Good to know, thank you. I hadn’t looked at the code, I was unaware it runs
through all the sprinklers.
2. Right, I know - the article was about it when it was an alias for
reclaimable, and hence describes some of the behavior of reclaimable.
3. Interesting, that’s good to know. I would
echo 1 > drop_caches does not generate memory pressure - it requests that the
page cache be cleared. It would not be expected to affect slab caches much.
You could try 3 (1+2 in this case, where 2 is inode and dentry). That might do
a bit more because some (maybe many?) of those objects
Actually i think it is just a bug with the way slab caches are created.
Some of them should be passed a flag that they are reclaimable.
i.e. something like:
https://patchwork.kernel.org/patch/9360819/
Regards.
Jacek Tomaka
On Sun, Apr 14, 2019 at 3:27 PM Jacek Tomaka wrote:
> Hello,
>
> TL;DR;
