> > On Thu, 20 Jun 2024 13:39:14 +0900 Sung-hun Kim <sfoon.kim@xxxxxxxxxxx> 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
