[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    kernel malloc
From:       Jonathan S. Shapiro jsshapiro () earthlink ! net
Date:       1998-05-03 19:01:21
[Download RAW message or body]

> Does this malloc handle "low memory" (first 640Kb), "DMA memory" (first
> 1Mb), or any type ?
> 
> For Intel architecture anyway.

This may now be moot, since I may or may not need malloc for in-kernel
packet buffering (I may statically allocate for now). The answer,
however, is "none of the above."

In the EROS kernel, there are two classes of memory allocation:
initialization time and run time.  At the moment, only initialization
allocation is implemented, as there were philosophical reasons to
disapprove of run time dynamic memory allocation (the issue is proving
non-deadlock).

This distinction is flawed, as it assumes that initialization time
precedes the allocation of the object cache.  Dynamic driver
installation might require altering this assumption.

INITIALIZATION TIME

Drivers can allocate physical memory meeting specific address range
requirements during their 'probe/attach' phase.  Memory allocated at
this level is NOT deallocatable, and once the initialization phase is
past you can't get any more.

The low-level DMA code allocates 4k bounce buffers during this phase
if the amount of physical memory on the machine indicates that they
might be needed.  Since the largest object that the present kernel
does DMA on is a page, this is adequate, and has eliminated the need
for address-constrained allocation in most of the drivers.  A few
remaining bits of code still use the interface to allocate big blocks
of contiguous memory (e.g. dynamic determination of process cache size
as a function of total available memory), but these request
unconstrained placement. [As a matter of implementation, they
therefore get high physical memory].

This eliminates the need for most of the places where you might expect
to see a physical address constraint; the need for a programmed copy
is hidden from the driver by the DMA logic.  I found that this made
the drivers clearer and eliminated the need for more pervasice
constraint mechanisms at higher levels of abstraction in the kernel.
Note also that the whole issue is going away as cards move to PCI.

RUN TIME

malloc() is the mechanism for run time allocation.

What malloc gets you is a block of memory whose virtual address is
translatable by the kernel.  There is no means to ask for a
restriction on the physical address, nor do I think it a good idea to
expose such a notion at this level of abstraction for the sake of
broken DMA chips given how quickly the broken DMA issue is going away.
The ISA bus doesn't move data fast enough to make the marginal copy a
problem anyway.


shap

[prev in list] [next in list] [prev in thread] [next in thread]