[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170419061149.GD2881@jagdpanzerIV.localdomain>
Date: Wed, 19 Apr 2017 15:11:49 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Minchan Kim <minchan@...nel.org>,
Christoph Lameter <cl@...ux.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-team@....com,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: copy_page() on a kmalloc-ed page with DEBUG_SLAB enabled (was
"zram: do not use copy_page with non-page alinged address")
On (04/18/17 13:06), Michal Hocko wrote:
[..]
> > > copy_page is a performance sensitive function and I believe that we do
> > > those tricks exactly for this purpose.
> >
> > a wild thought,
> >
> > use
> > #define copy_page(to,from) memcpy((to), (from), PAGE_SIZE)
> >
> > when DEBUG_SLAB is set? so arch copy_page() (if provided by arch)
> > won't be affected otherwise.
>
> SLAB is not guaranteed to provide page size aligned object AFAIR.
oh, if there are no guarantees for page_sized allocations regardless
the .config then agree, won't help.
-ss
Powered by blists - more mailing lists