[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikquj_2DE4UhTFAoDxL+1g=_BocCQJ5agrwC4NU@mail.gmail.com>
Date: Thu, 16 Sep 2010 10:34:53 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christopher Yeoh <cyeoh@....ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] Cross Memory Attach
On Thu, Sep 16, 2010 at 10:13 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>>
>> Over a copy_to/from_user? Not bloody likely.
>
> Gah, indeed. OK, since its not nested kmap() should indeed work. The
> alternative is using get_user_pages() on both address spaces, but I
> guess that makes things unnecessarily complex.
.. and perform horribly badly. And since the whole point was to do
this really efficiently, that's not good.
What *would* work would be to have a fast case that does kmap_atomic()
together with a copy_to/from_user_atomic(). And when that fast-case
fails, do the full kmap. Slightly more complex than the suggested
patch, but not horribly so (just a few more lines, no fundamental
complexities).
Of course, these days I would seriously suggest against trying to
optimize the kmap() case. It only matters on crap hardware these days.
Anybody running HIGHMEM in 2010 and thinks that it makes sense
deserves the pain the get. We should not complicate the kernel further
for it, and sane architectures will have a no-op kmap().
So the real cost there is likely not the kmap as much as the
set_page_dirty_lock() for the copy_to case. But you'd need to profile
it to see how big of a hit it is compared to the copy itself.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists