Re: Problem with >1 page GFP_KERNEL kmalloc()

Gerard Roudier (groudier@club-internet.fr)
Sun, 13 Apr 1997 20:21:14 +0000 (GMT)


Marek,

On Sun, 13 Apr 1997, Marek Michalkiewicz wrote:

> Hi,
>
> (sorry for the delay - my net access is somewhat limited at the moment)
>
> Gerard Roudier:
> > Any kernel software shall never try to allocate a physical memory area
> > larger that 1 PAGE a long time after the system has been booted up.
> > There is no guarantee that is always possible, and when it is, this may
> > cause lots of recently cached objects to be trashed or swapped out.
>
> OK, but this is not a disaster. The consequences of allocation failure
> may be much worse than that (like no nightly backup with ftape if the
> module fails to load).

I agree that is not generally a disaster. People are free to use this patch.
Remember the context in which I wrote this posting:
A patch that blindly free pages in order to allocate contiguous physical
memory was presented as a fix. My opinion is always that such a change is
worse than nothing.

> > I prefer such silly softwares to make problems to users, in order they
> > will be fixed more quickly.
>
> OK, but these "silly softwares" have been in the standard kernel for
> a few years, and so far nobody fixed them, so it must be non-trivial
> (and unlikely to be fixed in 2.0.xx). Instead, various ugly hacks
> are used to partially work around this limitation (see svgatextmode
> for an example - allocating and freeing lots of user memory in an
> attempt to create more free physical pages, resizing via 1x1 screen).

I did not know svgatextmode does such an ugly thing. It is indeed
worse than what the __get_free_pages() patch does but not very different
in my opinion.

> And if the purpose of these kmalloc failures is to encourage fixing
> bad kernel code more quickly, then an occasional "insmod ftape" or
> svgatextmode failure is not good enough - ALL >1 page kmallocs should
> always fail and be logged via printk (in 2.1.xx only, of course!).

Under Linux, the available memory is managed by severall different
objects. The central point of the balancing algorithm is
"try_to_free_pages()" that blindly calls object entry points in
order they free one page at least at a time.
With such an architecture, it is not possible to deal intelligently
with contiguous physical allocations, excepted at system startup.

If the patch had been stated:
- Work around for Linux used on personal systems by people who know
what they are doing,
all would have been ok for me.

--
Gerard.