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 compatibl
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 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_de
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_section
On Wed, Sep 29, 2010 at 14:37, Greg KH wrote:
> 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/dev
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 entrie
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 comman
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
> > >/s
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 functio
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 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 t
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
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 numbe
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 a
14 matches
Mail list logo
