?

Log in

No account? Create an account
linux source - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

linux source [Apr. 8th, 2004|02:19 am]
Brad Fitzpatrick
Tried to sleep a couple times but now for some reason I'm trying to read the source to Linux. It's surprisingly well documented.

In particular, I'm trying to figure what's responsible for freeing slab items of type "nfs_inode_cache" and "dentry_cache". Earlier today Lisa gave me the mystery of figuring out why two identical machines (hardware, software, roles, weighting) showed massively different amounts of free memory. (120 MB vs 500 MB). I looked at /proc/slabinfo and saw nfs_inode_cache and dentry_cache incredibly high on one, which I immediately recognized as find(1)'s fault, which was the only machine of ours with that not disabled.

So while I had confidence those cache items in the slabs would be reclaimed when necessary, I wanted to see the magic.

I've been looking at the slab, NFS, fs, and now VM code. Think I found what I was looking for:

mm/vmscan.c:try_to_free_pages -> shrink_slab

It's pretty cool... there's a "shrinker_list" of caches that can be shrunk with callbacks for the VM.

(easily amused at 2am)

So from there:

fs/dcache.c: set_shrinker(DEFAULT_SEEKS, shrink_dcache_memory);
fs/inode.c: set_shrinker(DEFAULT_SEEKS, shrink_icache_memory);

Now I'm curious if there's a way to invoke try_to_free_pages by hand, without waiting for the system memory to get low. I recognize it's not very useful, but I'm just curious.

I should sleep though or I won't get to work on time and be able wear my employee of the month shirt for the ~5th month in a row come May 1st.
LinkReply

Comments:
[User Picture]From: rrx
2004-04-08 04:00 am (UTC)

Linux VM

Hello,

Believe me ,as one
who use staying up in
the little hours - it is
really unefficinet to
work at night. (even if in the short run
you achieve some goals faster)


RRX
(Reply) (Thread)
[User Picture]From: mulix
2004-04-08 04:53 am (UTC)
Once upon a time, I wrote a patch that would let a) tie slab caches into sysfs, and b) let you set an upper bound on the size of a given slab cache. I lost it at a hard disk crash, but I could probably resurrect it if there was interest...
(Reply) (Thread)
[User Picture]From: brad
2004-04-08 08:43 am (UTC)
Would it let you change those at runtime? Could I effectively force a prune by lowering the ceiling, then removing it again?

If so, that'd be neat.

But I'll probably find a work-around to my current problem. (userspace naively looking at memfree to decide when to shrink itself.... should be looking at memfree + cached or similar)
(Reply) (Parent) (Thread)
[User Picture]From: brad
2004-07-06 08:33 pm (UTC)
Heh, I just googled for a related problem and found my own damn LiveJournal again. I hate it when that happens. :-)

So, uh, any hope of resurrecting that patch? :-)
(Reply) (Parent) (Thread)
[User Picture]From: mulix
2004-07-11 06:50 am (UTC)
Hope - sure, ETA - unknown :-)
I've been swamped with work lately... I'll take a look at it again during OLS, see what comes up. Too bad you won't be there...
(Reply) (Parent) (Thread)
[User Picture]From: xaosenkosmos
2004-04-08 08:07 am (UTC)
I should sleep though or I won't get to work on time and be able wear my employee of the month shirt for the ~5th month in a row come May 1st.

Wait, is that the only requirement? You do indeed set the HR policies, man ;^)

(Reply) (Thread)