From: James.Bottomley@HansenPartnership.com (James Bottomley)
To: linux-arm-kernel@lists.infradead.org
Subject: still nfs problems [Was: Linux 2.6.37-rc8]
Date: Wed, 05 Jan 2011 20:35:17 +0000 [thread overview]
Message-ID: <1294259717.16957.27.camel@mulgrave.site> (raw)
In-Reply-To: <AANLkTik214sj_wBJXhJMLRie34moG7ET1Xg62oQXsgxb@mail.gmail.com>
On Wed, 2011-01-05 at 11:49 -0800, Linus Torvalds wrote:
> 2011/1/5 James Bottomley <James.Bottomley@hansenpartnership.com>:
> >>
> >> No, we really can't do that. Most of the time, the kmap() is the only
> >> way we access the page anyway, so flushing things would just be
> >> stupid. Why waste time and energy on doing something pointless?
> >
> > It's hardly pointless. The kmap sets up an inequivalent alias in the
> > cache.
>
> NO IT DOES NOT.
Well, it does ... but not in this case because the page is freshly
allocated (which I missed before) so it has no use cache colour yet.
James
> Stop arguing, when you are so wrong.
>
> kmap() does not create any aliases. For low-memory, it just returns
> the physical address. No alias. And for high memory, there is no
> equivalent low memory address to alias _with_.
>
> Now, when you actually mix multiple kmap's and you have a virtually
> based cache, then the kmap's obviously need to flush that particular
> page when switching between each other. But that has nothing to do
> with the actual page being kmap'ed, it's entirely an internal issue
> about the particular virtual memory area being re-used. And ARM (and
> any other virtually based CPU) already does that in __kunmap_atomic().
>
> But notice the case of the low-mem. And understand that you are WRONG
> about the "inequivalent alias" thing.
>
> So I repeat: this has absolutely *NOTHING* to do with kmap(). Stop blathering.
>
> It's _purely_ an issue of vm_map_ram(). Nothing else.
>
> Linus
next prev parent reply other threads:[~2011-01-05 20:35 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 19:05 still nfs problems [Was: Linux 2.6.37-rc8] James Bottomley
2011-01-05 19:18 ` Linus Torvalds
2011-01-05 19:36 ` James Bottomley
2011-01-05 19:49 ` Linus Torvalds
2011-01-05 20:35 ` James Bottomley [this message]
2011-01-05 20:00 ` Russell King - ARM Linux
2011-01-05 20:33 ` James Bottomley
2011-01-05 20:48 ` Linus Torvalds
2011-01-05 21:04 ` Russell King - ARM Linux
2011-01-05 21:08 ` Linus Torvalds
2011-01-05 21:16 ` Trond Myklebust
2011-01-05 21:30 ` Linus Torvalds
2011-01-05 23:06 ` Trond Myklebust
2011-01-05 23:28 ` James Bottomley
2011-01-06 17:40 ` James Bottomley
2011-01-06 17:47 ` Trond Myklebust
2011-01-06 17:51 ` James Bottomley
2011-01-06 17:55 ` Linus Torvalds
2011-01-07 18:53 ` Trond Myklebust
2011-01-07 19:02 ` Russell King - ARM Linux
2011-01-07 19:11 ` James Bottomley
2011-01-08 16:49 ` Trond Myklebust
2011-01-08 23:15 ` Trond Myklebust
2011-01-10 10:50 ` Uwe Kleine-König
2011-01-10 16:25 ` Trond Myklebust
2011-01-10 17:08 ` Marc Kleine-Budde
2011-01-10 17:20 ` Trond Myklebust
2011-01-10 17:26 ` Marc Kleine-Budde
2011-01-10 19:25 ` Uwe Kleine-König
2011-01-10 19:29 ` Trond Myklebust
2011-01-10 19:31 ` James Bottomley
2011-01-10 19:34 ` Linus Torvalds
2011-01-10 20:15 ` Trond Myklebust
2011-01-10 12:44 ` Marc Kleine-Budde
2011-01-07 19:13 ` Trond Myklebust
2011-01-07 19:05 ` James Bottomley
2011-01-06 18:05 ` Russell King - ARM Linux
2011-01-06 18:14 ` James Bottomley
2011-01-06 18:25 ` James Bottomley
2011-01-06 21:07 ` James Bottomley
2011-01-06 20:19 ` John Stoffel
2011-01-05 23:28 ` Linus Torvalds
2011-01-05 23:59 ` Russell King - ARM Linux
2011-01-05 21:16 ` James Bottomley
[not found] <AANLkTi=-dNeeDjcSoznKtwcaNyw1mMXSqepFY89R2i+2@mail.gmail.com>
2010-12-30 17:14 ` Uwe Kleine-König
2010-12-30 17:57 ` Linus Torvalds
2010-12-30 18:24 ` Trond Myklebust
2010-12-30 18:50 ` Linus Torvalds
2010-12-30 19:25 ` Trond Myklebust
2010-12-30 20:02 ` Linus Torvalds
2010-12-30 17:59 ` Trond Myklebust
2010-12-30 19:18 ` Uwe Kleine-König
2011-01-03 21:38 ` Uwe Kleine-König
2011-01-04 0:22 ` Trond Myklebust
2011-01-05 8:40 ` Uwe Kleine-König
2011-01-05 11:05 ` Uwe Kleine-König
2011-01-05 11:27 ` Russell King - ARM Linux
2011-01-05 12:14 ` Marc Kleine-Budde
2011-01-05 13:02 ` Nori, Sekhar
2011-01-05 15:34 ` Russell King - ARM Linux
2011-01-05 13:40 ` Uwe Kleine-König
2011-01-05 14:29 ` Jim Rees
2011-01-05 14:42 ` Marc Kleine-Budde
2011-01-05 15:38 ` Jim Rees
2011-01-05 14:53 ` Trond Myklebust
2011-01-05 15:01 ` Marc Kleine-Budde
2011-01-05 15:14 ` Trond Myklebust
2011-01-05 15:29 ` Trond Myklebust
2011-01-05 15:39 ` Marc Kleine-Budde
2011-01-05 15:52 ` Russell King - ARM Linux
2011-01-05 17:17 ` Trond Myklebust
2011-01-05 17:26 ` Russell King - ARM Linux
2011-01-05 18:12 ` Trond Myklebust
2011-01-05 18:27 ` Russell King - ARM Linux
2011-01-05 18:55 ` Trond Myklebust
2011-01-05 19:07 ` Russell King - ARM Linux
2011-01-14 2:25 ` Andy Isaacson
2011-01-14 2:40 ` Trond Myklebust
2011-01-14 4:22 ` Andy Isaacson
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=1294259717.16957.27.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).