lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKYAXd91gcPbfAqRRkW7HhxRDXstzGVRbwqzve40z6BTDEj4_w@mail.gmail.com>
Date:	Sun, 20 Nov 2011 00:40:29 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	Theodore Tso <tytso@....edu>
Cc:	David Rientjes <rientjes@...gle.com>, linux-kernel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	Amit Sahrawat <amit.sahrawat83@...il.com>
Subject: Re: [PATCH] ext4: slab caches set to SLAB_MEM_SPREAD flags.

2011/11/19 Theodore Tso <tytso@....edu>:
>
> On Nov 19, 2011, at 8:52 AM, NamJae Jeon wrote:
>
>> 2011/11/18 Theodore Tso <tytso@....edu>:
>>>
>>> On Nov 17, 2011, at 10:11 AM, Theodore Tso wrote:
>>>>
>>>> So accessing non-local memory can be a really, really big deal.  And this
>>>> isn't just theoretical, but have you considered what might happen on a 8
>>>> core AMD machine?
>>>
>>> Sorry, typo.  This should have read, "have you considered what might happen on a 8 _socket_ AMD machine"?
>>>
>> You're right. but..
>> It is only useful using cpuset, And have you read cpuset spread
>> history link of Amit provided ?
>> And why have you still used spread flags for inode cache ?
>
> The inode cache is different for the following reasons:
>
> (1) The memory allocations are long-lived, and there is a good chance for many of them that they will be used by other CPU's on different NUMA nodes.
>
> (2)  There are a very large number of inodes, so uneven allocation of the inodes has a significantly larger impact.
>
> In contrast, the page_io and mballoc allocations are very short lived, there aren't a whole lot of them (check /proc/slabinfo), and they are guaranteed to be used during their very short lifetime on the local CPU node.   So the benefits of spreading them around are not that great, since they aren't that many of them, and downsides of potential 2x or 3x time to access memory is large.
>
Thanks for your opinion.
Have you thought that mem spread flags is not needed in group info
caches same with page_io and mballoc ?

> -- Ted
>
>
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ