Hello,
On Mon, Jan 07, 2013 at 11:37:22PM +0530, Viresh Kumar wrote:
> On 7 January 2013 20:34, Tejun Heo wrote:
> > The latter part "not using idle cpu just for processing work" does
> > apply to homogeneous systems too but as I wrote earlier work items
> > don&#x
Hello, Viresh.
On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
> Firstly the root cause of this patchset.
>
> Myself and some others in Linaro are working on ARM future cores:
> big.LITTLE systems.
> Here we have few very powerful, high power consuming cores (big,
> currently A15's)
Hello, Viresh.
On Fri, Jan 04, 2013 at 04:41:47PM +0530, Viresh Kumar wrote:
> I got a list of files where cpu/processor_id strings are found, which
> may break with
> this patch (still can't guarantee as i don't have knowledge of these
> drivers)...
...
> I am not sure what to do now :) , can yo
Hello, Viresh.
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
> Workqueues queues work on current cpu, if the caller haven't passed a
> preferred
> cpu. This may wake up an idle CPU, which is actually not required.
>
> This work can be processed by any CPU and so we must select a
Hello,
On Sun, Sep 30, 2012 at 05:46:45PM +0530, Viresh Kumar wrote:
> For the scheduler CPU is idle, if all below are true:
> - current task is idle task
> - nr_running == 0
> - wake_list is empty
>
> And during these conditions, there can be a timer running in background.
> And when we reach it
Hello, Viresh.
On Thu, Sep 27, 2012 at 02:34:05PM +0530, Viresh Kumar wrote:
> - A cpu has programmed a timer and is IDLE now.
> - CPU gets into interrupt handler due to timer and queues a work. As the CPU
> is
> currently IDLE, we can queue this work to some other CPU.
I'm still a bit confuse
Hello,
On Tue, Sep 25, 2012 at 04:06:08PM +0530, Viresh Kumar wrote:
> +config MIGRATE_WQ
> + bool "(EXPERIMENTAL) Migrate Workqueues to non-idle cpu"
> + depends on SMP && EXPERIMENTAL
> + help
> + Workqueues queues work on current cpu, if the caller haven't passed a
> + p
On Tue, Sep 25, 2012 at 04:06:07PM +0530, Viresh Kumar wrote:
> flush_delayed_work() and flush_delayed_work_sync() had major portion of code
> similar. This patch introduces another routine __flush_delayed_work() which
> contains the common part to avoid code duplication.
This part has seen a lot
On Mon, Jan 30, 2012 at 12:12:18PM -0600, Christoph Lameter wrote:
> > I thought it didn't. I rememer thinking about this and determining
> > that NULL can't be allocated for dynamic addresses. Maybe I'm
> > imagining things. Anyways, if it can return NULL for valid
> > allocation, it is a bug a
On Mon, Jan 30, 2012 at 11:22:14AM -0600, Christoph Lameter wrote:
> On Mon, 30 Jan 2012, Tejun Heo wrote:
>
> > Percpu pointers are in a different address space and using
> > ZERO_SIZE_PTR directly will trigger sparse address space warning.
> > Also, I'm no
Hello,
On Mon, Jan 30, 2012 at 11:58:52AM -0600, Christoph Lameter wrote:
> > No, NULL is never gonna be a valid return from any allocator including
> > percpu. Percpu allocator doesn't and will never do so.
>
> How do you prevent the percpu allocator from returning NULL? I thought the
> per cpu
On Mon, Jan 30, 2012 at 12:37:34PM +0400, Dmitry Antipov wrote:
> Fix pcpu_alloc() to return ZERO_SIZE_PTR if requested size is 0;
> fix free_percpu() to check passed pointer with ZERO_OR_NULL_PTR.
>
> Signed-off-by: Dmitry Antipov
> ---
> mm/percpu.c | 16 +++-
> 1 files changed,
Hello, Christoph.
On Mon, Jan 30, 2012 at 11:52:23AM -0600, Christoph Lameter wrote:
> We have two possibilities now:
>
> 1. We say that the value returned from the per cpu allocator is an opaque
> value.
>
> This means that we have to remove the NULL check from the free
> function.
On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> Percpu pointers are in a different address space and using
> ZERO_SIZE_PTR directly will trigger sparse address space warning.
> Also, I'm not entirely sure whether 16 is guaranteed to be unused in
> percpu address space
On Mon, Jan 30, 2012 at 11:22:57AM -0600, Christoph Lameter wrote:
> On Mon, 30 Jan 2012, Tejun Heo wrote:
>
> > On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> > > Percpu pointers are in a different address space and using
> > > ZERO_SIZE_PTR direct
On Mon, Jan 30, 2012 at 10:02:24AM -0800, Tejun Heo wrote:
> I thought it didn't. I rememer thinking about this and determining
> that NULL can't be allocated for dynamic addresses. Maybe I'm
> imagining things. Anyways, if it can return NULL for valid
> allocation
16 matches
Mail list logo
