On Tue, May 21, 2019 at 08:20:09PM +0100, Al Viro wrote:
> On Tue, May 21, 2019 at 05:30:27PM +0100, David Howells wrote:
>
> > If we can live with close_from(int first) rather than close_range(), then
> > this
> > can perhaps be done a lot more efficiently by:
> >
> > new =
On Tue, Feb 19, 2019 at 02:20:26PM +0100, Jan Kara wrote:
> Thanks for information. Yeah, that makes somewhat more sense. Can you ever
> see the failure if you disable CONFIG_TRANSPARENT_HUGEPAGE? Because your
> findings still seem to indicate that there' some problem with page
> migration and
On Wed, Jan 02, 2019 at 03:57:58PM -0500, Michael S. Tsirkin wrote:
> @@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy
> atomicity"
> for more information.
>
>
> +
> +
> In summary:
>
>(*) Control dependencies can order prior loads against later stores.
On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> > I believe that keeping the mm docs together will give better visibility of
> > what (little) mm documentation we have and will make the updates easier.
> > The documents that fit well into a certain topic could be linked there.
On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > implementation to restrict itself to, eg, only loading libraries in
> > the bottom 1GB to avoid applications who want to map huge things from
> > running out
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> >
From: Matthew Wilcox <mawil...@microsoft.com>
Alpha already had an optimised memset-16-bit-quantity assembler routine
called memsetw(). It has a slightly different calling convention
from memset16() in that it takes a byte count, not a count of words.
That's the same convention used by
From: Matthew Wilcox <mawil...@microsoft.com>
memset32() can be used to initialise these three arrays. Minor code
footprint reduction.
Signed-off-by: Matthew Wilcox <mawil...@microsoft.com>
---
drivers/scsi/sym53c8xx_2/sym_hipd.c | 11 +++
1 file changed, 3 insertions(+),
From: Matthew Wilcox <mawil...@microsoft.com>
Where possible, call memset16(), memmove() or memcpy() instead of using
open-coded loops. If an architecture doesn't define VT_BUF_HAVE_RW,
we can do that from the generic code. For the architectures which do
have special RW routines, usually
From: Matthew Wilcox <mawil...@microsoft.com>
zram was recently enhanced to support compressing pages with a repeating
pattern up to the size of an unsigned long. As part of the discussion,
we noted it would be nice if architectures had optimised routines
to fill regions of memory with pa
From: Matthew Wilcox <mawil...@microsoft.com>
zram was the motivation for creating memset_l(). Minchan Kim sees a 7%
performance improvement on x86 with 100MB of non-zero deduplicatable
data:
perf stat -r 10 dd if=/dev/zram0 of=/dev/null
vanilla:0.232050465 seconds time e
From: Matthew Wilcox <mawil...@microsoft.com>
These are single instructions on x86. There's no 64-bit instruction
for x86-32, but we don't yet have any user for memset64() on 32-bit
architectures, so don't bother to implement it.
Signed-off-by: Matthew Wilcox <mawil...@microsoft.com&g
From: Matthew Wilcox <mawil...@microsoft.com>
memset16(), memset32() and memset64() are like memset(), but allow the
caller to fill the destination with a multibyte pattern. memset_l()
and memset_p() allow the caller to use unsigned long and pointer
values respectively. memset64() is cur
13 matches
Mail list logo
