public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox