[NSWI004] A02 - malloc request limit

[R S]

Thank you all for your answers, they were very insightful.

>just curious, why would such a limit be useful?

Not really useful, just pretty. This all started because we got confused by
the fact that programs can ask the kernel for more memory (we forgot that
we were the kernel) and hence thought about a runtime extendable heap
implementation for which we designed a structure that only supported
allocation limited to 4kB (since our available memory is a multiple of
4kB). After we remembered that we are the kernel, we still considered that
design neat so decided to ask about its main drawback.

Thanks again,
Strnadlová from Milkyway

On Mon, 2 Nov 2020 at 09:09, Vojtech Horky <horky at d3s.mff.cuni.cz> wrote:

> Hello.
>
> Dne 02. 11. 20 v 7:37 Petr Tuma napsal(a):
> > Hello,
> >
> > just curious, why would such a limit be useful ? The only thing I can
> > think of is trying very hard to keep the headers very small (saving bits
> > on size fields), but even for that a limit of around 4KB seems to be
> > quite small - and besides, by now I think you have all seen how hard it
> > is to avoid the alignment restrictions, which means aiming for a header
> > smaller than 4B in your assignments does not make much sense (and
> > possibly 8B would me more reasonable than 4B).
>
> The question might have arouse after the discussion we had last Friday
> about page and heap allocator. I remember I said something around the
> lines that kernel objects are rarely big and heap allocator usually
> allocates rather small objects.
>
> For example, in Linux one is not supposed to allocate objects bigger
> than page size and use other allocators for that [1].
>
> [1] https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
>
>
> For your implementation, it depends on where the limit comes from. If
> you create some kind of slab allocator with predefined object sizes
> (such as in HelenOS [2]) then 4KB would be okay as it would be _very_
> easy to increase it to any value. However, if you choose this limit
> because you are unable to debug your implementation for bigger values,
> it is a completely different story.
>
> [2]
>
> https://github.com/HelenOS/helenos/blob/master/kernel/generic/src/mm/malloc.c#L49
>
> If you have some smart and very memory efficient implementation, where
> 4KB limit allows you to do some nice tricks, it is probably okay. I say
> probably, because if the implementation becomes totally unreadable and
> unmaintainable because of that, we will not be very happy about it.
>
> Note that for some time you will be using heap allocator to allocate
> thread stacks. It might be useful to have stack bigger than 4KB in
> certain cases (for debugging).
>
>
> > On 01/11/2020 23:08, František Trebuňa wrote:
> >> In the tests malloc asks for maximum o f 32 KB if Im not mistaken.
>
> Actually, heap/stress allocates up to 128 KB. But the tests do not fail
> if such allocation is not possible and try to allocate smaller blocks.
>
> Hope this helps,
> - VH
>
>
> >>
> >> Trebuňa
> >>
> >> On Sun, Nov 1, 2020, 22:33 R S <rstrnadlova at gmail.com
> >> <mailto:rstrnadlova at gmail.com>> wrote:
> >>
> >>     Hello,
> >>     can we limit how much memory can malloc ask for (for instance to
> >> 4056B) or can malloc theoretically ask for half our heap?
> >>
> >>     Thank you
> >>     Strnadlová from Milkyway
> >>     _______________________________________________
> >>     NSWI004 mailing list
> >>     NSWI004 at d3s.mff.cuni.cz <mailto:NSWI004 at d3s.mff.cuni.cz>
> >>     https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> >> <https://d3s.mff.cuni.cz/mailman/listinfo/nswi004>
> >>
> >>
> >> _______________________________________________
> >> NSWI004 mailing list
> >> NSWI004 at d3s.mff.cuni.cz
> >> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> >>
> > _______________________________________________
> > NSWI004 mailing list
> > NSWI004 at d3s.mff.cuni.cz
> > https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20201103/4e2171c3/attachment.htm>