On Tue, Feb 05, 2008 at 11:14:19AM +1100, David Chinner wrote:
> On Mon, Feb 04, 2008 at 11:09:59AM +0100, Nick Piggin wrote:
> > You get better behaviour in the slab and page allocators and locality
> > and cache hotness of memory. For example, I guess in a filesystem /
> > pagecache heavy workloa
On Mon, Feb 04 2008, Arjan van de Ven wrote:
> Jens Axboe wrote:
> >>I was imagining the patch a little bit differently (per-cpu tasks, do a
> >>wake_up from the driver instead of cpu nr testing up in blk, work
> >>queues, whatever), but we know how to iron out these kinds of details ;).
> >
> >per
On Mon, Feb 04, 2008 at 11:09:59AM +0100, Nick Piggin wrote:
> You get better behaviour in the slab and page allocators and locality
> and cache hotness of memory. For example, I guess in a filesystem /
> pagecache heavy workload, you have to touch each struct page, buffer head,
> fs private state,
On Mon, 2008-02-04 at 05:33 -0500, Jens Axboe wrote:
> As Andi mentions, we can look into making that lockless. For the initial
> implementation I didn't really care, just wanted something to play with
> that would nicely allow me to control both the submit and complete side
> of the affinity issue
On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote:
> Hi guys,
>
> Just had another way we might do this. Migrate the completions out to
> the submitting CPUs rather than migrate submission into the completing
> CPU.
Hi Nick, This was the first experiment I tried on a quad core four
pack
Jens Axboe wrote:
I was imagining the patch a little bit differently (per-cpu tasks, do a
wake_up from the driver instead of cpu nr testing up in blk, work
queues, whatever), but we know how to iron out these kinds of details ;).
per-cpu tasks/wq's might be better, it's a little awkward to jump
On Mon, Feb 04 2008, Zach Brown wrote:
> [ ugh, still jet lagged. ]
>
> > Hi Nick,
> >
> > When Matthew was describing this work at an LCA presentation (not
> > sure whether you were at that presentation or not), Zach came up
> > with the idea that allowing the submitting application control the
[ ugh, still jet lagged. ]
> Hi Nick,
>
> When Matthew was describing this work at an LCA presentation (not
> sure whether you were at that presentation or not), Zach came up
> with the idea that allowing the submitting application control the
> CPU that the io completion processing was occurring
On Mon, Feb 04 2008, Nick Piggin wrote:
> On Mon, Feb 04, 2008 at 11:12:44AM +0100, Jens Axboe wrote:
> > On Sun, Feb 03 2008, Nick Piggin wrote:
> > > On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> > >
> > > Hi guys,
> > >
> > > Just had another way we might do this. Migrate the com
On Mon, Feb 04, 2008 at 11:12:44AM +0100, Jens Axboe wrote:
> On Sun, Feb 03 2008, Nick Piggin wrote:
> > On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> >
> > Hi guys,
> >
> > Just had another way we might do this. Migrate the completions out to
> > the submitting CPUs rather than mi
> + q = &__get_cpu_var(call_single_queue);
> + spin_lock_irqsave(&q->lock, flags);
> + list_replace_init(&q->list, &list);
> + spin_unlock_irqrestore(&q->lock, flags);
I think you could do that lockless if you use a similar data structure
as netchannels (essentially a fixed size si
On Sun, Feb 03 2008, Nick Piggin wrote:
> On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> >
> > Second experiment which we did was migrating the IO submission to the
> > IO completion cpu. Instead of submitting the IO on the same cpu where the
> > request arrived, in this experiment t
On Mon, Feb 04, 2008 at 03:40:20PM +1100, David Chinner wrote:
> On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote:
> > David Chinner wrote:
> > >Hi Nick,
> > >
> > >When Matthew was describing this work at an LCA presentation (not
> > >sure whether you were at that presentation or n
On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote:
> David Chinner wrote:
> >Hi Nick,
> >
> >When Matthew was describing this work at an LCA presentation (not
> >sure whether you were at that presentation or not), Zach came up
> >with the idea that allowing the submitting application
David Chinner wrote:
Hi Nick,
When Matthew was describing this work at an LCA presentation (not
sure whether you were at that presentation or not), Zach came up
with the idea that allowing the submitting application control the
CPU that the io completion processing was occurring would be a good
On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote:
> On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> >
> > Second experiment which we did was migrating the IO submission to the
> > IO completion cpu. Instead of submitting the IO on the same cpu where the
> > request arrived,
On Sun, Feb 03, 2008 at 12:53:02PM +0200, Pekka Enberg wrote:
> Hi Nick,
>
> On Feb 3, 2008 11:52 AM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > +asmlinkage void smp_call_function_fast_interrupt(void)
> > +{
>
> [snip]
>
> > + while (!list_empty(&list)) {
> > + struct call_si
Hi Nick,
On Feb 3, 2008 11:52 AM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> +asmlinkage void smp_call_function_fast_interrupt(void)
> +{
[snip]
> + while (!list_empty(&list)) {
> + struct call_single_data *data;
> +
> + data = list_entry(list.next, struct call_si
On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
>
> Second experiment which we did was migrating the IO submission to the
> IO completion cpu. Instead of submitting the IO on the same cpu where the
> request arrived, in this experiment the IO submission gets migrated to the
> cpu that i
On Tue, Jul 31, 2007 at 05:55:13PM -0700, Suresh B wrote:
> On Wed, Aug 01, 2007 at 02:41:18AM +0200, Nick Piggin wrote:
> > On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote:
> > > task by taking away some of its cpu time. With CFS micro accounting,
> > > perhaps
> > > we can track irq, so
On Wed, Aug 01, 2007 at 02:41:18AM +0200, Nick Piggin wrote:
> On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote:
> > Yes, softirq context is one way. But just didn't want to penalize the
> > running
> > task by taking away some of its cpu time. With CFS micro accounting, perhaps
> > we can
On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote:
> On Tue, Jul 31, 2007 at 06:19:17AM +0200, Nick Piggin wrote:
> > On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote:
> > > So any suggestions for making this clean and acceptable to everyone?
> >
> > It is obviously a good idea to h
On Tue, Jul 31, 2007 at 06:19:17AM +0200, Nick Piggin wrote:
> On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote:
> > So any suggestions for making this clean and acceptable to everyone?
>
> It is obviously a good idea to hand over the IO at the point which
> requires the least number of ca
On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote:
> On Mon, Jul 30, 2007 at 11:20:04AM -0700, Christoph Lameter wrote:
> > On Fri, 27 Jul 2007, Siddha, Suresh B wrote:
>
> > > Observation #2: This introduces some migration overhead during IO
> > > submission.
> > > With the current protot
On Mon, Jul 30, 2007 at 11:20:04AM -0700, Christoph Lameter wrote:
> On Fri, 27 Jul 2007, Siddha, Suresh B wrote:
>
> > We have been looking into the linux kernel direct IO scalability issues with
> > database workloads. Comments and suggestions on our below experiments are
> > welcome.
>
> This
On Fri, 27 Jul 2007, Siddha, Suresh B wrote:
> We have been looking into the linux kernel direct IO scalability issues with
> database workloads. Comments and suggestions on our below experiments are
> welcome.
This was on an SMP system? These issues are much more pronounced on a NUMA
system. Th
We have been looking into the linux kernel direct IO scalability issues with
database workloads. Comments and suggestions on our below experiments are
welcome.
In the linux kernel, direct IO requests are not batched at the block layer.
i.e, as a new request comes in, the request get directly submi
27 matches
Mail list logo
