[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Implementing RLIMIT_AS
From: |
Diego Nieto Cid |
Subject: |
Re: [RFC] Implementing RLIMIT_AS |
Date: |
Sat, 21 Dec 2024 17:01:14 -0300 |
Hi,
On Sat, Dec 21, 2024 at 10:06:10PM +0300, Sergey Bugaev wrote:
>
> In case you don't realize, there's more than one kernel map.
> kernel_map is the main one, but there are also ipc_kernel_map and
> device_io_map, which are submaps of kernel_map, and others could
> potentially be added.
>
> The way to check if a map belongs to the kernel is vm_map_pmap(map) ==
> kernel_pmap.
>
Oh, I did see `ipc_kernel_map` but didn't realize they were connected :(
>
> > To be honest, I'm trying to make the zzuf testsuit pass. Currently it fails
> > on a test that exhausts memory[1] when the driver calls it with the memory
> > limited to 256M [2][3].
> >
> > [1] https://github.com/samhocevar/zzuf/blob/master/test/bug-memory.c
> > [2]
> > https://github.com/samhocevar/zzuf/blob/master/test/check-zzuf-M-max-memory#L41
> > [3] https://github.com/samhocevar/zzuf/blob/master/src/myfork.c#L261
>
> Hm, so that code doesn't exactly seem to care that it's address space
> size that it's limiting, as long as it's some way to limit memory
> usage.
>
Correct. Whatever it makes malloc to fail after allocating ~256M that get
setup through RLIMIT_AS.
>
> Now, limiting the amount of memory available to a task (or a group of
> tasks) is of course also very much justified and logical. I'm saying:
> let's think about the best design for this feature, and then, if it
> ends up being aligned with a feature that Unix has, we can expose it
> as that Unix feature at the Hurd/glibc level. But it may end up
> looking more like cgroup's memory.max than like RLIMIT_AS, for
> example.
Ok, now I have to do some research on cgroups, hehe.
>
> On the other hand, resource accounting is famously not
> properly doable in Mach — OSF Mach at least had ledgers (which were
> never functional AFAIK), ours doesn't even do that.
That's a pitty :( and also sounds like a lot of work to be done.
>
> Welp, I guess that does sound discouraging :|
No, it's ok. I know kernel hacking is generally hard, just wanted to see
how far I could go and it seems I'm getting near the boundaries of my
skills :P
Re: [RFC] Implementing RLIMIT_AS, Sergey Bugaev, 2024/12/20
Re: [RFC] Implementing RLIMIT_AS, Samuel Thibault, 2024/12/21