Re: [PATCH gnumach] smp: Create AP processor set and put all APs inside it

[Samuel Thibault]

Almudena Garcia, le dim. 11 févr. 2024 11:17:01 +0000, a ecrit:
> With this old patch I got to boot and executive a bunch of threads splitting 
> in multiple cpus
> 
> https://git.zammit.org/gnumach-sv.git/commit/?h=fixes&id=0fe92b6b52726bcd2976863d344117dad8d19694
> 
> With the patch I quote and latest modifications, we got success booting 4/5 
> times. 

Ok, but this patch is only making races less probable.

I.e. it is making the problems even harder to spot. We don't want that,
we rather want to corner problems so that we can more easily fix them.
Using psets is a way to corner problems: avoid them for most of the
system, and get exposed to the for selected pieces of the system.

> So I prefer to check which is the block of this that really cause the 
> problem.  

By making the races less probable it will be even harder to identify
what is posing the problem.

By being able to select which block gets exposed to parallelism, you can
selectively check which blocks work and which don't.

> Once booted, it usually only crash when i do high load harddisk operations, 
> so I think there are a condition race in rumpdisk.

Not necessarily rumpdisk, it can also be libpager, ext2fs, etc.

> But we prefer doesn't put this patch to upstream, or only apply for booting 
> process, to i can be able to investigate the scheduler and harddisk issues 
> without needing to enable all AP manually each time I boot the system in smp 
> mode. 

That's the point of the patch: now you can use psets to choose what
processes/translators you put in the slaves pset.

Samuel