Re: Problem with >1 page GFP_KERNEL kmalloc()

Gerard Roudier (groudier@club-internet.fr)
Mon, 31 Mar 1997 13:04:59 +0000 (GMT)


On Mon, 31 Mar 1997, Ingo Molnar wrote:

>
> On Sun, 30 Mar 1997, Gerard Roudier wrote:
>
> > On Sun, 30 Mar 1997, Harald Koenig wrote:
>
> > > well, could anyone please fix the floppy device driver as we sometimes
> > > get
> > >
> > > Unable to allocate DMA memory
>
> > That is not exactly the same problem in my opinion.
> > ISA DMA capable interfaces need bounce buffers. Such hardwares have been
> > designed when machines had very fiew memory and generally have very low
> > performances.
> > Making available a small pool of about 100K or a fiew more for such hardware
> > is not expensive and should work with normal performance.
>
> maybe Mark Hemment's VM implementation (which does page reaping) solves
> this problem too?

You are probably speeking about the slab allocator. I will look into
the corresponding code. I just think that it is only able to reape what
it has sowed by itself.

About the initial posting, I think that the suggested patch is not a
fix but a buggy work around.
Depends on what it is intended to really do.
If the problem was to allow modules that allocate ISA DMAable memory to
be able to perform initialisations, something like the following untested
and uncommented patch should be enough, in my opinion.

--- linux/mm/page_alloc.c.2.0.29 Fri Aug 16 21:07:08 1996
+++ linux/mm/page_alloc.c.work_around Mon Mar 31 12:15:17 1997
@@ -191,6 +191,9 @@
{
unsigned long flags;
int reserved_pages;
+#ifdef CONFIG_ALLOC_DMA_WORK_AROUND
+ int try = 0;
+#endif

if (order >= NR_MEM_LISTS)
return 0;
@@ -210,8 +213,12 @@
cli();
if ((priority==GFP_ATOMIC) || nr_free_pages > reserved_pages) {
RMQUEUE(order, dma);
- restore_flags(flags);
- return 0;
+#ifdef CONFIG_ALLOC_DMA_WORK_AROUND
+ if (priority==GFP_ATOMIC || (dma && try++>MAP_NR(high_memory))) {
+ restore_flags(flags);
+ return 0;
+ }
+#endif
}
restore_flags(flags);
if (priority != GFP_BUFFER && try_to_free_page(priority, dma, 1))
------------------------------------------------------------------------------
(try++ > MAP_NR(high_memory)) is an unclever test to avoid infinite loop)

It just assume (probably wrongly) that ISA DMA memory is only allocated
at initialisation steps.

In the real world, different goods are to be pooled separately and
waiting lists and/or stocks shall me managed, unless we prefered
to live in fine old mess.

Is Linux still a dream? Is Linux becoming something like a fine old mess?

About the memory management in an VM/OS, my opinion is that if we want
to handle memory chunks with a granularity thicker than 1 PAGE or
some atypical allocation as DMA ISA memory, the most simple way is
to use specific pools for each purpose.

I will look into the slab allocator and see how much I am wrong.

Regards, Gerard.