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 c
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
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, 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 the
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 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
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
> enou
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 a
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 mod
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
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 appropriat
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 n
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 i
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 a
(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 rat
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 c
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
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 cou
20 matches
Mail list logo
