Re: [RFC PATCH 1/7] Shrink struct vm_page size

[Samuel Thibault]

Sergey Bugaev, le lun. 03 juil. 2023 10:23:33 +0300, a ecrit:
> On Mon, Jul 3, 2023 at 3:02 AM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > I applied this, *but* I see:
> >
> >  *      Fields in this structure are locked either by the lock on the
> >  *      object that the page belongs to (O) or by the lock on the page
> >  *      queues (P).  [Some fields require that both locks be held to
> >  *      change that field; holding either lock is sufficient to read.]
> >
> > That's not going to work at all with bitfields...
> 
> Great point. (But I don't think this patch makes it any worse.)

Yes, that's why I applied it :)

> > We do need to sort this out by separating bitfields that are not
> > protected the same way, otherwise it's no wonder if SMP fails oddly.
> 
> This is really interesting, because Mach surely was developed for SMP
> from the start ("an OS for a parallel computer" was an explicit design
> goal, and M in Mach stands for multi-processor), so it must have
> worked for them.

Possibly they didn't use bitfields at the time and that came later as an
optimization that didn't pose problem on UP.

> But indeed I see that they have separated the bitfields in XNU, so we
> should too. Hopefully without blowing the struct size back up.

We can use unsigned char types to get rounded to 8bits only.

> Any feedback/comments on the rest of the series? Does forward entry
> coalescing work for you? Any issues / noticeable performance effects?

I don't have the time to really investigate.

Samuel