[haiku-development] Re: 64 bit physical addresses
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2010 18:07:37 +0200
On 2010-06-22 at 16:23:38 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > (I believe graphic card drivers can support DMA from/to user-provided
> > memory)
>
> While in theory yes, our drivers currently don't do that.
I saw support for it in the radeon driver, though have not checked whether
it is actually used.
> > I intend to add a boot loader safemode setting and a kernel settings
> > file
> > option to enable/disable PAE. So there are essentially the following
> > options:
> >
> > 1. Don't build PAE support in.
> > 2. Build PAE support in, but make it opt-in via kernel settings.
> > 3. Build PAE support in, but make it opt-out via kernel settings.
> >
> > Opinions?
>
> Since it is only used when needed, 3. sounds like the best option to
> me.
>
> I'm not sure translating all 32 bit area creations as contiguous is a
> good idea, as that may greatly hurt the performance (not just
> speedwise).
ATM our page allocation backend simply doesn't support restrictions for
non-contiguous allocations and I don't see that happen anytime soon. To do
that efficiently one would have to add new data structures (e.g. use a
radix tree for the free/used pages). In most cases the allocations were
already contiguous anyway. I only changed a few from B_FULL_LOCK to
B_32_BIT_MEMORY (mostly in network drivers).
Do you think we should rather introduce two lock constants, e.g.
B_32_BIT_FULL_LOCK and B_32_BIT_CONTIGUOUS to at least allow for specifying
the exact constraints, even if the backend always returns contiguous memory
for the time being?
CU, Ingo
Other related posts:
