public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: pte-highmem-5
Date: Wed, 16 Jan 2002 14:30:39 -0500	[thread overview]
Message-ID: <20020116143039.C12216@redhat.com> (raw)
In-Reply-To: <20020116185814.I22791@athlon.random> <Pine.LNX.4.33.0201161008270.2112-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0201161008270.2112-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, Jan 16, 2002 at 10:19:56AM -0800

On Wed, Jan 16, 2002 at 10:19:56AM -0800, Linus Torvalds wrote:
>  - please don't do that "pte_offset_atomic_irq()" have special support in
>    the header files: it is _not_ a generic operation, and it is only used
>    by the x86 page fault logic. For that reason, I would suggest moving
>    all that logic out of the header files, and into i386/mm/fault.c,
>    something along the lines of
> 
> 	pte = pte_offset_nokmap(..)
> 	addr = kmap_atomic(pte, KM_VMFAULT);
> 
>    instead of having special magic logic in the header files.

Ah, here's where I come in and say that kmap_atomic stinks and needs to be 
replaced. ;-)  If you take a look at code in various places making use of 
atomic kmaps, some of the more interesting cases (like bio) have to disable 
irqs during memory copies in order to avoid races on reuse of an atomic 
kmap.  I think that's a sign of an interface that needs redesign.  My 
proposal: make kmap_atomic more like kmap in that it allocates from a pool, 
but make the pool per cpu with ~4 entries reserved per context.  The only 
concern I have is that we might not be restricting the depth of irq entry 
currently, but I'm not familiar with that code.  Time to code up a patch...

> Other than that it looks fairly straightforward, I think.

Agreed.

		-ben

  parent reply	other threads:[~2002-01-16 19:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-16 17:58 pte-highmem-5 Andrea Arcangeli
2002-01-16 18:04 ` pte-highmem-5 Linus Torvalds
2002-01-16 18:35   ` pte-highmem-5 Andrea Arcangeli
2002-01-16 18:19 ` pte-highmem-5 Linus Torvalds
2002-01-16 18:48   ` pte-highmem-5 Andrea Arcangeli
2002-01-16 19:11     ` pte-highmem-5 Linus Torvalds
2002-01-16 19:30       ` pte-highmem-5 Andrea Arcangeli
2002-01-16 19:30   ` Benjamin LaHaise [this message]
2002-01-16 19:50     ` pte-highmem-5 Andrea Arcangeli
2002-01-16 19:34   ` pte-highmem-5 Rik van Riel
2002-01-17  8:31 ` pte-highmem-5 Christoph Rohland
2002-01-17 12:14   ` pte-highmem-5 Hugh Dickins
2002-01-17 15:45     ` pte-highmem-5 Andrea Arcangeli
2002-01-17 16:08       ` pte-highmem-5 Hugh Dickins
2002-01-17 15:30   ` pte-highmem-5 Andrea Arcangeli
2002-01-17 16:11     ` pte-highmem-5 Christoph Rohland
2002-01-17 16:37       ` pte-highmem-5 Andrea Arcangeli
2002-01-17 17:31       ` pte-highmem-5 Rik van Riel
2002-01-17 17:57 ` pte-highmem-5 Hugh Dickins
2002-01-17 18:09   ` pte-highmem-5 Andrea Arcangeli
2002-01-17 19:02     ` pte-highmem-5 Hugh Dickins
2002-01-18  2:38       ` pte-highmem-5 Andrea Arcangeli
2002-01-19 20:56         ` pte-highmem-5 Hugh Dickins
2002-01-21 18:15           ` pte-highmem-5 Andrea Arcangeli
2002-01-22 18:01             ` pte-highmem-5 Hugh Dickins
2002-01-22 19:10               ` pte-highmem-5 Andrea Arcangeli
2002-01-22 21:41                 ` pte-highmem-5 Hugh Dickins
2002-01-22 23:34                   ` pte-highmem-5 Andrea Arcangeli
2002-01-23  0:56                     ` pte-highmem-5 Paul Mackerras
2002-01-23  1:27                       ` pte-highmem-5 Andrea Arcangeli
2002-01-23  5:38                     ` pte-highmem-5 Hugh Dickins
2002-01-23 16:29                       ` pte-highmem-5 Daniel Phillips
2002-01-23 20:23                         ` pte-highmem-5 Hugh Dickins
2002-01-24  3:09                       ` pte-highmem-5 Andrea Arcangeli
2002-01-24 15:35                         ` pte-highmem-5 Hugh Dickins
2002-01-22 19:29             ` pre4aa1 contig kmaps patch Hugh Dickins
2002-01-23 13:31               ` rwhron

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=20020116143039.C12216@redhat.com \
    --to=bcrl@redhat.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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