[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161007170842.GQ19539@ZenIV.linux.org.uk>
Date: Fri, 7 Oct 2016 18:08:42 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Brian Boylston <brian.boylston@....com>
Cc: linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org,
toshi.kani@....com, oliver.moreno@....com,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH] use a nocache copy for bvecs in copy_from_iter_nocache()
On Fri, Oct 07, 2016 at 10:55:11AM -0500, Brian Boylston wrote:
> copy_from_iter_nocache() is only "nocache" for iovecs. Enhance it to also
> use a nocache copy for bvecs. This improves performance by 2-3X when
> splice()ing to a file in a DAX-mounted, pmem-backed file system.
> +static void memcpy_from_page_nocache(char *to, struct page *page, size_t offset, size_t len)
> +{
> + char *from = kmap_atomic(page);
> + __copy_from_user_inatomic_nocache(to, from, len);
> + kunmap_atomic(from);
> +}
At the very least, it will blow up on any architecture with split
userland and kernel MMU contexts. You *can't* feed a kernel pointer
to things like that and expect it to work. At the very least, you
need to add memcpy_nocache() and have it default to memcpy(), with
non-dummy version on x86. And use _that_, rather than messing with
__copy_from_user_inatomic_nocache()
Powered by blists - more mailing lists