On 07/25/2013 08:15 AM, Kay Sievers wrote:
> Complexity, well, it's just a bit of code which belongs in the kernel.
> The mentioned unconditional hotplug loop through userspace is
> absolutely pointless. Such defaults never belong in userspace tools if
> they do not involve data that is only availa
canonical.com;
> a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory blocks
>
>
On Thu, Jul 25, 2013 at 5:03 PM, Dave Hansen wrote:
> On 07/25/2013 04:14 AM, KY Srinivasan wrote:
>> As promised, I have sent out the patches for (a) an implementation of an
>> in-kernel API
>> for onlining and a consumer for this API. While I don't know the exact
>> reason why the
>> user mod
On 07/25/2013 04:14 AM, KY Srinivasan wrote:
> As promised, I have sent out the patches for (a) an implementation of an
> in-kernel API
> for onlining and a consumer for this API. While I don't know the exact
> reason why the
> user mode code is delayed (under some low memory conditions), what i
a...@canonical.com; a...@firstfloor.org; a...@linux-foundation.org; linux-
> m...@kvack.org; kamezawa.hiroy...@gmail.com; han...@cmpxchg.org;
> ying...@google.com; jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory
On Wed 24-07-13 14:02:32, Dave Hansen wrote:
> On 07/24/2013 12:45 PM, KY Srinivasan wrote:
> > All I am saying is that I see two classes of failures: (a) Our
> > inability to allocate memory to manage the memory that is being hot added
> > and (b) Our inability to bring the hot added memory online
On 07/24/2013 12:45 PM, KY Srinivasan wrote:
> All I am saying is that I see two classes of failures: (a) Our
> inability to allocate memory to manage the memory that is being hot added
> and (b) Our inability to bring the hot added memory online within a reasonable
> amount of time. I am not sure
t; a...@canonical.com; a...@firstfloor.org; a...@linux-foundation.org; linux-
> m...@kvack.org; kamezawa.hiroy...@gmail.com; han...@cmpxchg.org;
> ying...@google.com; jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory b
On 07/23/2013 10:21 AM, KY Srinivasan wrote:
>> You have allocated some large, physically contiguous areas of memory
>> under heavy pressure. But you also contend that there is too much
>> memory pressure to run a small userspace helper. Under heavy memory
>> pressure, I'd expect large, kernel al
canonical.com;
> a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory block
@linux-foundation.org; linux-
> m...@kvack.org; kamezawa.hiroy...@gmail.com; mho...@suse.cz;
> han...@cmpxchg.org; ying...@google.com; jasow...@redhat.com;
> k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory blocks
>
> On F
On Fri, Jul 19, 2013 at 12:23:05PM -0700, K. Y. Srinivasan wrote:
> The current machinery for hot-adding memory requires having udev
> rules to bring the memory segments online. Export the necessary functionality
> to to bring the memory segment online without involving user space code.
>
> Signe
On 07/23/2013 08:54 AM, KY Srinivasan wrote:
>> > Adding memory usually requires allocating some large, contiguous areas
>> > of memory for use as mem_map[] and other VM structures. That's really
>> > hard to do under heavy memory pressure. How are you accomplishing this?
> I cannot avoid failure
canonical.com;
> a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory block
...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory blocks
>
> On Tue
On 07/23/2013 07:52 AM, KY Srinivasan wrote:
> The current scheme of involving user
> level code to close this loop obviously does not perform well under high
> memory pressure.
Adding memory usually requires allocating some large, contiguous areas
of memory for use as mem_map[] and other VM str
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> > kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> > jasow...@redhat.com; k...@vrfy.org
> > Subject:
...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org;
> kamezawa.hiroy...@gmail.com; han...@cmpxchg.org; ying...@google.com;
> jasow...@redhat.com; k...@vrfy.org
> Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining
> memory blocks
>
> On Fri 19
On Fri 19-07-13 12:23:05, K. Y. Srinivasan wrote:
> The current machinery for hot-adding memory requires having udev
> rules to bring the memory segments online. Export the necessary functionality
> to to bring the memory segment online without involving user space code.
Why? Who is going to use
On 07/20/2013 03:23 AM, K. Y. Srinivasan wrote:
> The current machinery for hot-adding memory requires having udev
> rules to bring the memory segments online. Export the necessary functionality
> to to bring the memory segment online without involving user space code.
According to udev guys, ude
20 matches
Mail list logo
