From: "Stephen C. Tweedie" <sct@redhat.com>
To: Shuvabrata Ganguly <sganguly@cse.iitkgp.ernet.in>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux MM <linux-mm@kvack.org>
Subject: Re: Question about pte_alloc()
Date: Wed, 15 Nov 2000 15:47:29 +0000 [thread overview]
Message-ID: <20001115154729.H3186@redhat.com> (raw)
In-Reply-To: <3A132470.4F93CFF5@cse.iitkgp.ernet.in>; from sganguly@cse.iitkgp.ernet.in on Wed, Nov 15, 2000 at 07:04:00PM -0500
Hi,
On Wed, Nov 15, 2000 at 07:04:00PM -0500, Shuvabrata Ganguly wrote:
> "Stephen C. Tweedie" wrote:
>
> > On Wed, Nov 15, 2000 at 02:07:38AM -0500, Shuvabrata Ganguly wrote:
> > > it appears from the code that pte_alloc() might block since it allocates
> > > a page table with GFP_KERNEL if the page table doesnt already exist. i
> > > need to call pte_alloc() at interrupt time.
> >
> > You cannot safely play pte games at interrupt time. You _must_ do
> > this in the foreground.
>
> why is that ?
Because the locking mechanisms used to protect ptes on SMP machines
are not interrupt-safe, and because even on uni-processors, we may
perform non-atomic operations on the page tables (such as various
read-modify-write cycles) which will break if an interrupt occurs in
the middle of the cycle and modifies the pte.
> > Why can't you just let the application know that the event has
> > occurred and then let it mmap the data itself?
>
> Two reasons:-
> i) since kernel memory is unswappable i dont want to allocate a big buffer
> and transfer it to the user when the device has filled it with data. instead
> i want to allocate a page, fill it with data and give it to the user process.
>
> ii) if i allocate in pages and let the user know that a page of data has
> arrived, it will take a lot of context switches.
I don't buy that. The user process _has_ to wait if there's no data
ready, surely? It doesn't matter how you are passing the data around.
> basically i want the kernel to allocate memory on behalf of a process, and
> pass the virtual address of that buffer to the user when it does a read. this
> is somewhat like the "fbuf" scheme.
There are a number of ways you could do that without messiness in the
VM. You could allocate a small number of pages at once, mmap()
them and use that as a ring buffer to the application. Basically,
establishing a new kernel buffer mapping from user space IS the mmap()
operation --- why not use mmap for it? The corresponding munmap when
the application has finished using the data lets the kernel know
exactly when the page can be recycled.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-11-15 15:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-15 7:07 Question about pte_alloc() Shuvabrata Ganguly
2000-11-14 20:51 ` Kanoj Sarcar
2000-11-15 10:56 ` Stephen C. Tweedie
2000-11-16 0:04 ` Shuvabrata Ganguly
2000-11-15 15:47 ` Stephen C. Tweedie [this message]
2000-11-16 20:32 ` Shuvabrata Ganguly
2000-11-16 14:37 ` Ingo Oeser
-- strict thread matches above, loose matches on Subject: below --
2000-11-15 15:20 Mark_H_Johnson
2000-11-15 15:34 ` Stephen C. Tweedie
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=20001115154729.H3186@redhat.com \
--to=sct@redhat.com \
--cc=linux-mm@kvack.org \
--cc=sganguly@cse.iitkgp.ernet.in \
/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.