Re: [PATCH] accounting per process swapped out pages

[Mulyadi Santosa]

Hi ...

> 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 
me...

Refined patch will follow ASAP..

regards,

Mulyadi

-
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/