RE: [PATCH v2] mm: ksm: Consider the number of ksm_mm_slot in the general_profit calculation

["Sung-hun Kim" <sfoon.kim@samsung.com>]

> > On Thu, 20 Jun 2024 13:39:14 +0900 Sung-hun Kim <sfoon.kim@samsung.com> wrote:
> >
> > > The current version of KSM does not take into account the number of
> > > used ksm_mm_slot. Therefore, when users want to obtain profits of
> > > KSM, KSM omits the memory used for allocating ksm_mm_slots.
> > >
> > > This patch introduces a new variable to keep track of the number of
> > > allocated ksm_mm_slots. By doing so, KSM will be able to provide a
> > > more accurate number of the gains made.
> > >
> >
> > By how much does the improve the accuracy?  In other words, how much difference does this make?
> >
> 
> I think it makes only small difference. (few kilobytes for hundreds of processes)
> 
> 
> > > @@ -3672,7 +3680,8 @@ static ssize_t general_profit_show(struct kobject *kobj,
> > >  	long general_profit;
> > >
> > >  	general_profit = (ksm_pages_sharing + atomic_long_read(&ksm_zero_pages)) * PAGE_SIZE -
> > > -				ksm_rmap_items * sizeof(struct ksm_rmap_item);
> > > +				ksm_rmap_items * sizeof(struct ksm_rmap_item) -
> > > +				atomic_long_read(&ksm_mm_slots) * sizeof(struct ksm_mm_slot);
> > >
> > >  	return sysfs_emit(buf, "%ld\n", general_profit);
> >
> > This assumes perfect slab packing, no?   Should it use ksize()?
> 
> Ah, thanks for your recommendation. It should be fixed.
> 

I'm sorry. I found a mistake in my previous mail. I think ksize() does not fit in this context.

ksize() should be used for the allocated object. But the calculation just uses the number of
allocated ksm_mm_slots and sizeof() for the data structure like ksm_rmap_item.
The calculated profit is an approximation of real value because the object does not
be perfectly packed as you said.


Best regards,
Sung-hun Kim