All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Harries <bha@gmx.de>
To: mingo@elte.hu
Cc: linux-kernel@vger.kernel.org
Subject: Re: __get_free_pages(): is the MEM really mine?
Date: Sun, 30 Sep 2001 14:59:01 +0200	[thread overview]
Message-ID: <3BB71715.A57FA7D4@gmx.de> (raw)
In-Reply-To: <Pine.LNX.4.33.0109300914490.1665-100000@localhost.localdomain>

Ingo Molnar wrote:

> This is a property of Linux's buddy allocator. If you allocate a 9th order
> 'big page', that does not mean you can free the pages one by one.

I used  free_pages((ULONG)card_ptr->dma_blk0[n], max_order); before Roman 
changed it. And still do for minor 26 now...

> while unconventional, doing this is safe. There is nothing in the page
> structure that says that the page was allocated as a higher order page.

> But the above is an 'internal' property of
> the Linux page allocator, so it's not guaranteed to stay so forever.

Thats why I don't like it so much. But it seems I must do it for some strange
reason:

On minor 26 I do it the old way, on minor 27 I use Romans fix. What shall I say:
Reading and writing to the buffer allocated with Roman's fix so far never
crashed the system. But doing it the normal way (minor 26) how I also learned it
from A. Rubini's book, 
does harm to the system.

After usage of the normally allocated buffer the strangest thing occur:
- Issing w caused a dump on the console once.
- Halt doesn't really halt the system completely
- Reboot caused everything to hang, partitions still dirty...


> (the Linux kernel does not do the above for understandable reasons: it
> takes a loop of 512 iterations to fix up the page counts in the above way,
> which is noticeable runtime overhead.)

Oh yes, indeed! But:

Is there a guarantee that the n - 1 pages above the 1st one are not donated to
other programs while my driver uses them?


> is it a fundamental property of the hardware that it needs a continuous
> physical memory buffer?

Yes. The FW on the card demands it.

> Being able to allocate a 2 MB page is only guaranteed during bootup. There
> is just no mechanizm in Linux that guarantees it for you to be able to
> allocate a 2 MB page (let alone two adjacent 2 MB pages), in even a
> moderately utilized system. Scatter-gather avoids all these problems.

I'll move the code to init_module later once it is stable.

Ciao,
-- 
Bernd Harries

bha@gmx.de           http://www.freeyellow.com/members/bharries
bha@nikocity.de       Tel. +49 421 809 7343 priv.  | MSB First!
harries@stn-atlas.de       +49 421 457 3966 offi.  | Linux-m68k
bernd@linux-m68k.org      8.48'21" E  52.48'52" N  | Medusa T40
           <>_<>      _______                _____
       .---|'"`|---. |  |_|  |_|_|_|_|_|_|_ (_____)  .-----.
______`o"O-OO-OO-O"o'`-o---o-'`-oo-----oo-'`-o---o-'`-o---o-'___

  reply	other threads:[~2001-09-30 12:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-27 10:06 __get_free_pages(): is the MEM really mine? Bernd Harries
2001-09-27 13:00 ` Ingo Molnar
2001-09-29 17:15   ` Bernd Harries
2001-09-30  7:27     ` Ingo Molnar
2001-09-30 12:59       ` Bernd Harries [this message]
2001-10-01  5:55         ` Ingo Molnar
2001-10-05  8:49           ` Bernd Harries
  -- strict thread matches above, loose matches on Subject: below --
2001-10-01 11:33 Bernd Harries
2001-10-05 12:55 ` Hugh Dickins
2001-10-05 13:32   ` Bernd Harries
2001-10-05 15:27     ` Hugh Dickins
2001-09-27 14:19 Bernd Harries
2001-09-27  8:56 Bernd Harries
2001-09-27  9:15 ` Ingo Molnar
2001-09-27  9:20 ` Ingo Molnar
2001-09-27 14:38 ` Eric W. Biederman
2001-09-29  7:32   ` Bernd Harries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BB71715.A57FA7D4@gmx.de \
    --to=bha@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.