On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote:
> Further digging seems to indicate 9984d7394618df9, the one right
> after the commit I previously identified.
> Not sure what I did wrong with my bisect to put it off by one.
Ugh... Can't reproduce here ;-/ Could you give more
On 04/08/2013 10:58 AM, Al Viro wrote:
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I
On 04/08/2013 10:58 AM, Al Viro wrote:
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
> On 04/05/2013 04:00 PM, Al Viro wrote:
> >On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
> >
> >>That didn't produce anything. I'll run some bisections over the
> >>weekend and see what I can sort out.
> >*Ugh*
> >
>
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I can sort out.
*Ugh*
I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry
and exit
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I can sort out.
*Ugh*
I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry
and exit
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I can sort out.
*Ugh*
I'd try to
On 04/08/2013 10:58 AM, Al Viro wrote:
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I
On 04/08/2013 10:58 AM, Al Viro wrote:
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
On 04/05/2013 04:00 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I
On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote:
Further digging seems to indicate 9984d7394618df9, the one right
after the commit I previously identified.
Not sure what I did wrong with my bisect to put it off by one.
Ugh... Can't reproduce here ;-/ Could you give more
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
> That didn't produce anything. I'll run some bisections over the
> weekend and see what I can sort out.
*Ugh*
I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry
and exit from close_pdeo(). If that doesn't show
On 04/05/2013 12:36 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote:
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote:
> On 04/04/2013 03:44 PM, Al Viro wrote:
> >On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
> >
> >>Ok I am cloning the tree now.
> >>It does look like the patches would conflict.
> >>I'll run some tests and take a
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run some tests and take a deeper look.
FWIW, I've just pushed there a tentative patch that switches to
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run some tests and take a deeper look.
FWIW, I've just pushed there a tentative patch that switches to
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote:
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run some tests and take a deeper look.
FWIW,
On 04/05/2013 12:36 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote:
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
That didn't produce anything. I'll run some bisections over the
weekend and see what I can sort out.
*Ugh*
I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry
and exit from close_pdeo(). If that doesn't show
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
> Ok I am cloning the tree now.
> It does look like the patches would conflict.
> I'll run some tests and take a deeper look.
FWIW, I've just pushed there a tentative patch that switches to hopefully
saner locking (head should be at
On 04/04/2013 11:11 AM, Al Viro wrote:
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote:
This moves a kfree outside a spinlock to help scaling on larger (512 core)
systems. This should be some relief until we can move the section to use
the rcu.
Umm... That'll get wrecked as
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote:
> This moves a kfree outside a spinlock to help scaling on larger (512 core)
> systems. This should be some relief until we can move the section to use
> the rcu.
Umm... That'll get wrecked as soon as fixes from #experimental go in;
This moves a kfree outside a spinlock to help scaling on larger (512 core)
systems. This should be some relief until we can move the section to use
the rcu.
I ran a simple test which just reads from /proc/cpuinfo.
Lower is better, as you can see the worst case scenario is improved.
This moves a kfree outside a spinlock to help scaling on larger (512 core)
systems. This should be some relief until we can move the section to use
the rcu.
I ran a simple test which just reads from /proc/cpuinfo.
Lower is better, as you can see the worst case scenario is improved.
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote:
This moves a kfree outside a spinlock to help scaling on larger (512 core)
systems. This should be some relief until we can move the section to use
the rcu.
Umm... That'll get wrecked as soon as fixes from #experimental go in;
On 04/04/2013 11:11 AM, Al Viro wrote:
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote:
This moves a kfree outside a spinlock to help scaling on larger (512 core)
systems. This should be some relief until we can move the section to use
the rcu.
Umm... That'll get wrecked as
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run some tests and take a deeper look.
FWIW, I've just pushed there a tentative patch that switches to hopefully
saner locking (head should be at
26 matches
Mail list logo
