[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFT] Re: Policy-based memory allocations (was Re: RFC: 1.97 roadmap)

From: Vladimir 'phcoder' Serbinenko
Subject: [RFT] Re: Policy-based memory allocations (was Re: RFC: 1.97 roadmap)
Date: Sun, 16 Aug 2009 21:35:37 +0200

I have this "thingie" available at my git branches mm and mm+move but
it needs more testing. Unless it's tested enough it should be
postponed and not included in 1.97.
Actually I don't understand why it was proposed to include it in 1.97
at all - it changes memory management, bugs in it are likely to be
critical and benefit is only smaller core. If it was up to me I would
just postpone it. But it's possible to put it in 1.97 if someone tests
it enough.
Personally I think nested partition patch should go in 1.97 since it's
more tested and provides useful feature namely: (together with 2
smaller patches) ability to boot solaris.

On Thu, Aug 13, 2009 at 11:01 PM, Vladimir 'phcoder'
Serbinenko<address@hidden> wrote:
>> But available memory is several orders of magnitude bigger than the largest
>> block a loader will need.  So is this really an issue?
> It's not always the case. Two examples
> 1) Solaris. At least some distributions of solaris use a big (70 MiB
> compressed, around 200 MiB compressed) initrd which has to be loaded
> as multiboot module in a single chunk. This puts biggest needed chunk
> in the same order of magnitude as RAM available on some smaller
> systems.
> 2) XNU hibernating. It requires booter to load hibernating image in a
> single chunk. Even though it's compressed it can easily be 50% of
> total RAM or more
>> --
>> Robert Millan
>>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>>  how) you may access your data; but nobody's threatening your freedom: we
>>  still allow you to remove your data and not access it at all."
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
> --
> Regards
> Vladimir 'phcoder' Serbinenko
> Personal git repository:

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]