On 09/29/2010 02:37 PM, Greg KH wrote:
Thankfully things like rpm, hald, and other miscellaneous commands scan
that information.
Really? Why? Why would rpm care about this? hald is dead now so we
don't need to worry about that anymore,
That's not what compatiblity means.
On 09/29/2010 02:28 PM, Robin Holt wrote:
On Tue, Sep 28, 2010 at 01:17:33PM -0500, Nathan Fontenot wrote:
On 09/28/2010 07:38 AM, Robin Holt wrote:
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
On Wed, Sep 29, 2010 at 02:28:30PM -0500, Robin Holt wrote:
On Tue, Sep 28, 2010 at 01:17:33PM -0500, Nathan Fontenot wrote:
...
My next task is to implement a x86_64 SGI UV specific chunk of code
to memory_block_size_bytes(). Would you consider adding that to your
patch set? I expect to
On 09/29/2010 04:50 AM, Greg KH wrote:
Because the old ABI creates 129,000+ entries inside
/sys/devices/system/memory with their associated links from
/sys/devices/system/node/node*/ back to those directory entries.
Thankfully things like rpm, hald, and other miscellaneous commands
On Wed, Sep 29, 2010 at 10:32:34AM +0200, Avi Kivity wrote:
On 09/29/2010 04:50 AM, Greg KH wrote:
Because the old ABI creates 129,000+ entries inside
/sys/devices/system/memory with their associated links from
/sys/devices/system/node/node*/ back to those directory entries.
On Tue, Sep 28, 2010 at 01:17:33PM -0500, Nathan Fontenot wrote:
On 09/28/2010 07:38 AM, Robin Holt wrote:
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I made a dramatic improvement on a 16TB machine in that function by
merely caching the most recent memory section
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB) there are perfomance issues
related to creating the large
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote:
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB)
On Tue, 2010-09-28 at 14:44 +0200, Avi Kivity wrote:
Why not update sysfs directory creation to be fast, for example by using
an rbtree instead of a linked list. This fixes an implementation
problem in the kernel instead of working around it and creating a new ABI.
New ABIs mean old tools
On 09/28/2010 05:12 PM, Robin Holt wrote:
Why not update sysfs directory creation to be fast, for example by
using an rbtree instead of a linked list. This fixes an
implementation problem in the kernel instead of working around it
and creating a new ABI.
Because the old ABI creates
On 09/28/2010 07:38 AM, Robin Holt wrote:
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I made a dramatic improvement on a 16TB machine in that function by
On Tue, Sep 28, 2010 at 10:12:18AM -0500, Robin Holt wrote:
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote:
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB) there are perfomance issues
related to creating the large number of sysfs directories. For
a powerpc machine
14 matches
Mail list logo
