Kent Overstreet writes:
> On Fri, Feb 08, 2013 at 03:49:02PM +0100, Jens Axboe wrote:
[...]
>> I'd feel a lot better deferring the whole aio/dio performance series for
>> one merge window. There's very little point in rushing it, and I don't
>> think it's been reviewed/tested enough yet.
>
> It
Kent Overstreet koverstr...@google.com writes:
On Fri, Feb 08, 2013 at 03:49:02PM +0100, Jens Axboe wrote:
[...]
I'd feel a lot better deferring the whole aio/dio performance series for
one merge window. There's very little point in rushing it, and I don't
think it's been reviewed/tested
On Fri, Feb 08, 2013 at 03:49:02PM +0100, Jens Axboe wrote:
> On Fri, Feb 08 2013, Tejun Heo wrote:
> > (cc'ing Andrew)
> >
> > On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> > > This implements a refcount with similar semantics to
> > > atomic_get()/atomic_dec_and_test(),
On Fri, Feb 08, 2013 at 06:44:08AM -0800, Tejun Heo wrote:
> (cc'ing Andrew)
>
> On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> > This implements a refcount with similar semantics to
> > atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> > but
On Fri, 8 Feb 2013 15:49:02 +0100 Jens Axboe wrote:
> > > Signed-off-by: Kent Overstreet
> >
> > What's the status of this series? The percpu-refcnt part is still
> > going through review and the merge window is opening up pretty soon.
> > Kent, Andrew?
>
> I'd feel a lot better deferring
On Fri, Feb 08 2013, Tejun Heo wrote:
> (cc'ing Andrew)
>
> On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> > This implements a refcount with similar semantics to
> > atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> > but dynamically switches to per cpu
(cc'ing Andrew)
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> This implements a refcount with similar semantics to
> atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> but dynamically switches to per cpu refcounting when the rate of
> gets/puts becomes
(cc'ing Andrew)
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu refcounting when the rate of
gets/puts becomes too
On Fri, Feb 08 2013, Tejun Heo wrote:
(cc'ing Andrew)
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu
On Fri, 8 Feb 2013 15:49:02 +0100 Jens Axboe ax...@kernel.dk wrote:
Signed-off-by: Kent Overstreet koverstr...@google.com
What's the status of this series? The percpu-refcnt part is still
going through review and the merge window is opening up pretty soon.
Kent, Andrew?
I'd feel a
On Fri, Feb 08, 2013 at 06:44:08AM -0800, Tejun Heo wrote:
(cc'ing Andrew)
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically
On Fri, Feb 08, 2013 at 03:49:02PM +0100, Jens Axboe wrote:
On Fri, Feb 08 2013, Tejun Heo wrote:
(cc'ing Andrew)
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out
On Mon, 28 Jan 2013, Kent Overstreet wrote:
> > It goes down to how we allocate page tables. percpu depends on
> > vmalloc space allocation which in turn depends on page table
> > allocation which unfortunately assumes GFP_KERNEL and is spread all
> > across different architectures. Adding @gfp
On Mon, Jan 28, 2013 at 09:59:51AM -0800, Tejun Heo wrote:
> Hello, Kent.
>
> On Mon, Jan 28, 2013 at 09:53:04AM -0800, Kent Overstreet wrote:
> > > Like Tejun, I'd prefer to see it always alloc up-front, because it
> > > avoids the _noalloc variant (which is backwards: please hand gfp_t, so
> >
Hello, Kent.
On Mon, Jan 28, 2013 at 09:48:58AM -0800, Kent Overstreet wrote:
> > Ooh, I forgot one thing. We might not gain much by replacing file
> > refcnt w/ this. You can't really get cheaper than fget_light().
>
> I've seen fget() show up when profiling the aio code - it's not high
>
Hello, Kent.
On Mon, Jan 28, 2013 at 09:53:04AM -0800, Kent Overstreet wrote:
> > Like Tejun, I'd prefer to see it always alloc up-front, because it
> > avoids the _noalloc variant (which is backwards: please hand gfp_t, so
> > you don't hide the alloc) and heuristics.
>
> Problem with gfp_t is
On Fri, Jan 25, 2013 at 04:45:10PM +1030, Rusty Russell wrote:
> Tejun Heo writes:
> >> It also implements two stage shutdown, as we need it to tear down the
> >> percpu counts. Before dropping the initial refcount, you must call
> >> percpu_ref_kill(); this puts the refcount in "shutting down
On Thu, Jan 24, 2013 at 06:09:43PM -0800, Tejun Heo wrote:
> Hello, again.
>
> On Thu, Jan 24, 2013 at 06:03:40PM -0800, Tejun Heo wrote:
> > Yeah, if we're aiming to replace refcnts in file and kobj, dynamic
> > alloc may be justified. Hopefully, the accounting necessary to decide
> > whethre
On Thu, Jan 24, 2013 at 06:09:43PM -0800, Tejun Heo wrote:
Hello, again.
On Thu, Jan 24, 2013 at 06:03:40PM -0800, Tejun Heo wrote:
Yeah, if we're aiming to replace refcnts in file and kobj, dynamic
alloc may be justified. Hopefully, the accounting necessary to decide
whethre to use
On Fri, Jan 25, 2013 at 04:45:10PM +1030, Rusty Russell wrote:
Tejun Heo t...@kernel.org writes:
It also implements two stage shutdown, as we need it to tear down the
percpu counts. Before dropping the initial refcount, you must call
percpu_ref_kill(); this puts the refcount in shutting
Hello, Kent.
On Mon, Jan 28, 2013 at 09:53:04AM -0800, Kent Overstreet wrote:
Like Tejun, I'd prefer to see it always alloc up-front, because it
avoids the _noalloc variant (which is backwards: please hand gfp_t, so
you don't hide the alloc) and heuristics.
Problem with gfp_t is
Hello, Kent.
On Mon, Jan 28, 2013 at 09:48:58AM -0800, Kent Overstreet wrote:
Ooh, I forgot one thing. We might not gain much by replacing file
refcnt w/ this. You can't really get cheaper than fget_light().
I've seen fget() show up when profiling the aio code - it's not high
enough to
On Mon, Jan 28, 2013 at 09:59:51AM -0800, Tejun Heo wrote:
Hello, Kent.
On Mon, Jan 28, 2013 at 09:53:04AM -0800, Kent Overstreet wrote:
Like Tejun, I'd prefer to see it always alloc up-front, because it
avoids the _noalloc variant (which is backwards: please hand gfp_t, so
you don't
On Mon, 28 Jan 2013, Kent Overstreet wrote:
It goes down to how we allocate page tables. percpu depends on
vmalloc space allocation which in turn depends on page table
allocation which unfortunately assumes GFP_KERNEL and is spread all
across different architectures. Adding @gfp to it
Tejun Heo writes:
>> It also implements two stage shutdown, as we need it to tear down the
>> percpu counts. Before dropping the initial refcount, you must call
>> percpu_ref_kill(); this puts the refcount in "shutting down mode" and
>> switches back to a single atomic refcount with the
Hello, again.
On Thu, Jan 24, 2013 at 06:03:40PM -0800, Tejun Heo wrote:
> Yeah, if we're aiming to replace refcnts in file and kobj, dynamic
> alloc may be justified. Hopefully, the accounting necessary to decide
> whethre to use percpu isn't too burdensome.
Ooh, I forgot one thing. We might
Hey,
Regurgitating stuff which came up during chat for the record.
On Thu, Jan 24, 2013 at 05:13:45PM -0800, Kent Overstreet wrote:
> I was envisioning something with low enough overhead that we could use
> it for the refcounts in struct file and kref/kobject - I've seen both of
> those show up
On Thu, Jan 24, 2013 at 04:51:36PM -0800, Tejun Heo wrote:
> (cc'ing percpu / rcu crowd)
>
> Hello, Kent.
>
> On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> > This implements a refcount with similar semantics to
> > atomic_get()/atomic_dec_and_test(), that starts out as just
(cc'ing percpu / rcu crowd)
Hello, Kent.
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
> This implements a refcount with similar semantics to
> atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> but dynamically switches to per cpu refcounting when the
(cc'ing percpu / rcu crowd)
Hello, Kent.
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu refcounting when the rate
On Thu, Jan 24, 2013 at 04:51:36PM -0800, Tejun Heo wrote:
(cc'ing percpu / rcu crowd)
Hello, Kent.
On Wed, Dec 26, 2012 at 06:00:02PM -0800, Kent Overstreet wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an
Hey,
Regurgitating stuff which came up during chat for the record.
On Thu, Jan 24, 2013 at 05:13:45PM -0800, Kent Overstreet wrote:
I was envisioning something with low enough overhead that we could use
it for the refcounts in struct file and kref/kobject - I've seen both of
those show up in
Hello, again.
On Thu, Jan 24, 2013 at 06:03:40PM -0800, Tejun Heo wrote:
Yeah, if we're aiming to replace refcnts in file and kobj, dynamic
alloc may be justified. Hopefully, the accounting necessary to decide
whethre to use percpu isn't too burdensome.
Ooh, I forgot one thing. We might not
Tejun Heo t...@kernel.org writes:
It also implements two stage shutdown, as we need it to tear down the
percpu counts. Before dropping the initial refcount, you must call
percpu_ref_kill(); this puts the refcount in shutting down mode and
switches back to a single atomic refcount with the
On Thu, Jan 03, 2013 at 02:48:39PM -0800, Andrew Morton wrote:
> On Wed, 26 Dec 2012 18:00:02 -0800
> Kent Overstreet wrote:
>
> > This implements a refcount with similar semantics to
> > atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> > but dynamically switches to per
On Thu, Jan 03, 2013 at 02:48:39PM -0800, Andrew Morton wrote:
On Wed, 26 Dec 2012 18:00:02 -0800
Kent Overstreet koverstr...@google.com wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically
On Wed, 26 Dec 2012 18:00:02 -0800
Kent Overstreet wrote:
> This implements a refcount with similar semantics to
> atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
> but dynamically switches to per cpu refcounting when the rate of
> gets/puts becomes too high.
>
> It also
On Wed, 26 Dec 2012 18:00:02 -0800
Kent Overstreet koverstr...@google.com wrote:
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu refcounting when the rate of
gets/puts becomes too
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu refcounting when the rate of
gets/puts becomes too high.
It also implements two stage shutdown, as we need it to tear down the
percpu
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test(), that starts out as just an atomic_t
but dynamically switches to per cpu refcounting when the rate of
gets/puts becomes too high.
It also implements two stage shutdown, as we need it to tear down the
percpu
40 matches
Mail list logo
