[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Resident memory set size



Michael Kelly, le lun. 12 mai 2025 15:38:48 +0100, a ecrit:
> On 12/05/2025 08:45, Samuel Thibault wrote:
> 
>     The issue could match the issues I'm still experiencing on buildds where
>     I have just disabled swap.
> 
> 
>         It is the page balancing that is reducing the resident memory
>         total for my first process. Each page that is moved gets marked
>         as VM_PROT_NONE and the task's (pmap) resident_count decremented
>         accordingly. There doesn't seem to be any equivalent increment
>         associated with the page that it is moved to.
> 
>     That's odd indeed, do you have the series of calls that leads to the
>     decrement? (e.g. a backtrace)
> 
> It is just the code path through vm_page_seg_balance_page():

Ok. I'm wondering if it's not just a side effect that only _looks_
odd.  It is expected that the balancing code unmaps the page from the
process.  Possibly gnumach doesn't bother with remapping it, because it
does not really *have* to, it can as well just defer that until the page
is really needed again. And thus the RSS of the process stays lower in
the meanwhile. Reading the pages again from userland would make gnumach
have to remap them. Normally it will be able to find them in the memory
object.

> *) The page data is then copied from old to new. There is a call to
> pmap_clear_modify for the new page if the old page wasn't 'dirty'

Yes, because have have just written to the new page, so of course the
hardware dirty flag is set, but we don't want to infer from that that
the page is dirty if it wasn't already, so we clear the hardware flag.

> but what about the case where the old page was dirty?

In that case the memcpy(&dest->vm_page_header, &src->vm_page_header)
will have copied the dirtiness information. The hardware page flag will
also have a modified bit from the memcpy, but that's fine since the page
was already marked dirty.

>     Your test case is valid, it'll be useful to investigate further.
> 
> I'm spending a lot of time trying to unravel the workings of the memory
> management.

Just making sure: have you studied memory management from some book
already? Code comments don't usually repeat what is written there.

Samuel


Reply to: