[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170531.125118.94140984076231176.davem@davemloft.net>
Date: Wed, 31 May 2017 12:51:18 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: mhocko@...nel.org
Cc: pasha.tatashin@...cle.com, linux-kernel@...r.kernel.org,
sparclinux@...r.kernel.org, linux-mm@...ck.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
borntraeger@...ibm.com, heiko.carstens@...ibm.com
Subject: Re: [v3 0/9] parallelized "struct page" zeroing
From: Michal Hocko <mhocko@...nel.org>
Date: Wed, 31 May 2017 18:31:31 +0200
> On Tue 30-05-17 13:16:50, Pasha Tatashin wrote:
>> >Could you be more specific? E.g. how are other stores done in
>> >__init_single_page safe then? I am sorry to be dense here but how does
>> >the full 64B store differ from other stores done in the same function.
>>
>> Hi Michal,
>>
>> It is safe to do regular 8-byte and smaller stores (stx, st, sth, stb)
>> without membar, but they are slower compared to STBI which require a membar
>> before memory can be accessed.
>
> OK, so why cannot we make zero_struct_page 8x 8B stores, other arches
> would do memset. You said it would be slower but would that be
> measurable? I am sorry to be so persistent here but I would be really
> happier if this didn't depend on the deferred initialization. If this is
> absolutely a no-go then I can live with that of course.
It is measurable. That's the impetus for this work in the first place.
When the do the memory barrier, the whole store buffer flushes because
the memory barrier is done with a dependency on the next load or store
operation, one of which the caller is going to do immediately.
Powered by blists - more mailing lists