Re: [PATCH] accounting per process swapped out pages
From: Mulyadi Santosa
Date: Fri Aug 04 2006 - 20:59:17 EST
> To be honest, I don't think there's much interest in this particular
> VmSwp statistic; and if there's little interest in it, we'd rather
> not spend the time and space on collecting it. But I could be wrong:
> let's see who speaks up for it.
I got the same impression too, but I do think this statistic is
important if someone wants to know which program suffers most when
(heavy) swapping happens. Some programs like "top" would also get
benefit since its "swapped" accounting is just based on virtual-rss,
which is wrong (just showing parts that haven't been brought to RAM)
> You waste space in every vm_area_struct for your swapped_out count,
> then /proc/<pid>/status has to loop over the vmas adding them up.
> Much better to make it an mm_counter like anon_rss, then you only
> use space in mm_struct, and don't have to add them up at the end,
> and avoid dirtying (vma) cachelines unnecessarily, and (in some
> cases) avoid the atomic operations.
Let's see if I can adapt this idea. Actually, in the first place, I was
thinking this way but sometimes it is easier to get pointer to
vm_area_struct rather than to mm_struct. I'll take a deeper look...
Avoiding atomic operation is also my another primary target....
> While you've caught the main places where you'd need to adjust
> swapped_out, you've missed a couple (maybe I've missed more):
> copy_pte_range (fork) needs to increment the count, zap_pte_range
> (munmap or truncate or exit) needs to decrement it. Check wherever
> anon_rss is adjusted, some not all would need swapped_out adjusted.
Yes, I use anon_rss a the "guidance" on where I probably put the
swapped_out accounting and decide whether it actually has anything to
do with swapping or not. Hmmmm, looks like I still miss a lot...
> Oh, you are doing something in zap_pte_range, but I'm sorry to say
> what you do there is nonsense: the number you're subtracting has
> nothing to do with the number of swapped out pages.
:( OK, re-checking...
> And you probably wouldn't want that printk in your final patch!
Perfect closing, i forgot to clean that printk(). Thanks for reminding
Refined patch will follow ASAP..
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/