linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Manfred Spraul" <masp0008@stud.uni-sb.de>
To: linux-mm@kvack.org
Subject: Ramdisk for > 1GB / >2 GB
Date: Mon, 1 Feb 1999 22:25:54 +0100	[thread overview]
Message-ID: <004401be4e29$fb998300$c80c17ac@clmsdev> (raw)

I've written a ramdisk driver that can use physical, unmapped memory. I've
posted a beta version this morning to linux-kernel.
Basically, it is a kernel patch that manages the memory (alloc_hugemem(),
free_hugemem()), and a block device driver that can use this memory.

I'm new in the Linux MM, perhaps you could help me on these questions:

1) SMP:
I use a spinlock for every ramdisk, and one page for each drive as a window
to the physical memory. Since only 1 processor uses this page, I can use
__flush_tlb_one( == INVLPG only on the local processor) without any further
synchronization.
Is that stable on SMP, and do you think that this parallel enough?
Linus suggested using one 4MB pte for each processor, but I think that this
would be to much overhead.
Another idea would be using a hash table (eg. 32 spinlocks, 32 pages) that
is shared by all processors.

2) I can't make the driver a module because I use 'pgt_offset_k()' to
traverse the page tables, but init_mm is not exported.
Is there any other way how I can find the pte_t that belongs to my page?

3) Is more than 2 GB memory a problem that only applies to the i386
architecture, or is there demand for that on PowerPC, Sparc32?

Regards,
    Manfred

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

             reply	other threads:[~1999-02-01 21:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-01 21:25 Manfred Spraul [this message]
1999-02-02  7:54 ` Eric W. Biederman
1999-02-04  7:20 ` ralf

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='004401be4e29$fb998300$c80c17ac@clmsdev' \
    --to=masp0008@stud.uni-sb.de \
    --cc=linux-mm@kvack.org \
    /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