public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Harries <mlbha@gmx.de>
To: linux-kernel@vger.kernel.org
Cc: mingo@elte.hu
Subject: Re: __get_free_pages(): is the MEM really mine?
Date: Thu, 27 Sep 2001 16:19:06 +0200 (MEST)	[thread overview]
Message-ID: <11776.1001600346@www23.gmx.net> (raw)

Ingo Molnar wrote:

> well - what did you expect to happen? A freed page is going to be reused
> for other purposes. A big 2MB allocation can be reused in part, once
> memory usage grows.

With my knowledge, I expected exactly that.

> So you should not expect the device to be able to DMA
> into a page that got freed, unpunished.

I am not. The DMA ioctl() finishes before the close() -> free happens after
the hexdump and the DMA. The buffer is allocated in open. The fact that I get
the same buffer again next time shows that the free is sucessful and
effective, right?

Sep 27 11:43:28 pcma73 kernel: rsc_open() minor=$1B 
Sep 27 11:43:28 pcma73 kernel:  DMA blk 0 at KV:$CE800000 BUS:$0E800000 
Sep 27 11:43:28 pcma73 kernel:  DMA blk 1 at KV:$CE600000 BUS:$0E600000
contig < 

Sep 27 11:43:28 pcma73 kernel:  Collected DMA Buffer1 at KS:$0000CE600000

Sep 27 11:43:28 pcma73 kernel: rsc_ioctl()
Sep 27 11:43:28 pcma73 kernel:  RSC_IOC_DMA_OUT

Sep 27 11:43:28 pcma73 kernel: rsc_close()

Sep 27 11:43:28 pcma73 kernel:  Free DMA blk 0 at KS:$CE800000 
Sep 27 11:43:28 pcma73 kernel:  Free DMA blk 1 at KS:$CE600000 

> Perhaps i'm misunderstanding the problem.

My problem is, I'm out of ideas. All I can think of is describe as much as
possible the relevant things that I do and the things that occur. Maybe
someone more experienced recognizes a principal flaw in the concept.

> Plus, if you allocate a 2MB
> physically continuous chunk then the likelyhood is high that there were
> fragmented pages skipped during the initial search for a 2MB block - so
> you still have a fair likelyhood to reallocate it after some time, if
> memory usage is light. But this likelyhood nears zero once RAM usage gets
> near 100%.

And I can rely on the fact that all the 2 MB are contig memory without
holes, right? It's completely mine, isn't it?
Or is it perhaps illegal to let the mem usage pump?
Should I better allocate the mem in init_module() instead of rsc_open()?
Probably page tables are more likely to get corrupted than they would be if
I allocate only once. Or do I have to use a spin_lock somewhere in the nopage
method?


>From my tests I'm ready the believe the 1st page really _is_ mine but now
I'm not so sure all the 
(1 << 9) pages really are.

If I don't access the pages, just allocate them and free them after some
time, I never saw any instabilities. But it seems that as soon as I access pages
above the 1st in the buffer, something gets corrupted. So maybe today it's
only legal to allocate 1 page at a time and I have to do that 
(1<<10) times...

Or maybe some of the VM trouble I read about recntly would also cover my
problems?

Thanks,

-- 
Bernd Harries

bha@gmx.de            http://bharries.freeyellow.com
bharries@web.de       Tel. +49 421 809 7343 priv.  | MSB First!
harries@stn-atlas.de       +49 421 457 3966 offi.  | Linux-m68k
bernd@linux-m68k.org       +49 172 139 6054 handy  | Medusa T40

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


             reply	other threads:[~2001-09-27 14:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-27 14:19 Bernd Harries [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-10-01 11:33 __get_free_pages(): is the MEM really mine? 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 10:06 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
2001-10-01  5:55         ` Ingo Molnar
2001-10-05  8:49           ` 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=11776.1001600346@www23.gmx.net \
    --to=mlbha@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