On 09/26/2013 05:58 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 17:42:52 -0400 Peter Hurley
wrote:
On 09/26/2013 02:05 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley
wrote:
The issue with a single large kmalloc is that it may fail where
3 separate,
On Thu, 26 Sep 2013 17:42:52 -0400 Peter Hurley
wrote:
> On 09/26/2013 02:05 PM, Andrew Morton wrote:
> > On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley
> > wrote:
> >
> >> The issue with a single large kmalloc is that it may fail where
> >> 3 separate, page-or-less kmallocs would not have.
On 09/26/2013 02:05 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley
wrote:
The issue with a single large kmalloc is that it may fail where
3 separate, page-or-less kmallocs would not have.
Or vmalloc fails first, because of internal fragmentation of the vmap
arena.
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley
wrote:
> The issue with a single large kmalloc is that it may fail where
> 3 separate, page-or-less kmallocs would not have.
Or vmalloc fails first, because of internal fragmentation of the vmap
arena. This problem plus vmalloc's slowness are
On 09/26/2013 11:04 AM, Greg KH wrote:
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could
On 09/26/2013 11:32 AM, Andi Kleen wrote:
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
> On 09/25/2013 11:20 PM, Andi Kleen wrote:
> >Lin Ming writes:
> >>
> >>Would you like below patch?
> >
> >The loop body keeps rather complex state. It could easily
> >get confused by parallel RCU changes.
> >
> >So if the list
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
> On 09/26/2013 03:33 AM, Andrew Morton wrote:
> >On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
> >wrote:
> >
> >>Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> >>could definitely be reduced (even
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So if the list changes in parallel you may suddenly
report very bogus values, as the va_start - prev_end
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project for
another day :)
20bafb3d23d10
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
wrote:
> Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> could definitely be reduced (even nearly eliminated), but that's a project for
> another day :)
20bafb3d23d10 ("n_tty: Move buffers into n_tty_data") switched
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project for
another day :)
20bafb3d23d10 (n_tty: Move buffers into
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project for
another day
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming min...@gmail.com writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So if the list changes in parallel you may suddenly
report very bogus values, as the
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming min...@gmail.com writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So if the list changes
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be
On 09/26/2013 11:32 AM, Andi Kleen wrote:
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming min...@gmail.com writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel
On 09/26/2013 11:04 AM, Greg KH wrote:
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
Looking over vmalloc.c, the critical section footprint of the
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
The issue with a single large kmalloc is that it may fail where
3 separate, page-or-less kmallocs would not have.
Or vmalloc fails first, because of internal fragmentation of the vmap
arena. This problem plus
On 09/26/2013 02:05 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
The issue with a single large kmalloc is that it may fail where
3 separate, page-or-less kmallocs would not have.
Or vmalloc fails first, because of internal
On Thu, 26 Sep 2013 17:42:52 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
On 09/26/2013 02:05 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
The issue with a single large kmalloc is that it may fail where
3 separate,
On 09/26/2013 05:58 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 17:42:52 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
On 09/26/2013 02:05 PM, Andrew Morton wrote:
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley pe...@hurleysoftware.com
wrote:
The issue with a single large kmalloc
Lin Ming writes:
>
> Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So if the list changes in parallel you may suddenly
report very bogus values, as the va_start - prev_end
computation may be bogus.
Perhaps it's ok
On Wed, 2013-09-25 at 07:30 -0400, Peter Hurley wrote:
> On 09/25/2013 05:04 AM, Lin Ming wrote:
> > On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley
> > wrote:
> > [snip]
> >>
> >> Looking over vmalloc.c, the critical section footprint of the
> >> vmap_area_lock
> >> could definitely be reduced
On Wed, Sep 25, 2013 at 7:30 PM, Peter Hurley wrote:
> On 09/25/2013 05:04 AM, Lin Ming wrote:
>>
>> On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley
>> wrote:
>> [snip]
>>>
>>>
>>> Looking over vmalloc.c, the critical section footprint of the
>>> vmap_area_lock
>>> could definitely be reduced
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project
for
another day :)
Hi Peter,
I also
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley wrote:
[snip]
>
> Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> could definitely be reduced (even nearly eliminated), but that's a project
> for
> another day :)
Hi Peter,
I also looked over vmallo.c, but didn't find
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project
for
another day :)
Hi Peter,
I also looked over
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definitely be reduced (even nearly eliminated), but that's a project
for
another day
On Wed, Sep 25, 2013 at 7:30 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com
wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the
vmap_area_lock
could
On Wed, 2013-09-25 at 07:30 -0400, Peter Hurley wrote:
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com
wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the
vmap_area_lock
could definitely be
Lin Ming min...@gmail.com writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So if the list changes in parallel you may suddenly
report very bogus values, as the va_start - prev_end
computation may be bogus.
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley
Date: Sat Jun 15 10:21:19
On 09/17/2013 07:22 PM, Fengguang Wu wrote:
On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote:
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote:
> On 09/12/2013 09:09 PM, Fengguang Wu wrote:
> >On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> >>Hi Peter,
> >>
> >>FYI, we noticed much increased vmap_area_lock contentions since this
> >>commit:
> >>
> >>commit
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley
Date: Sat Jun 15 10:21:19
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley pe...@hurleysoftware.com
Date:
On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote:
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit
On 09/17/2013 07:22 PM, Fengguang Wu wrote:
On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote:
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
On 09/12/2013 09:09 PM, Fengguang Wu wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley pe...@hurleysoftware.com
Date:
On Mon, Sep 16, 2013 at 10:42:11PM -0400, Peter Hurley wrote:
> On 09/12/2013 11:38 PM, Fengguang Wu wrote:
> >On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> >>On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> >>>Hi Peter,
> >>>
> >>>FYI, we noticed much increased
On 09/12/2013 11:38 PM, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
What does that mean? What is happening,
On 09/12/2013 11:38 PM, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
What does that mean? What is happening,
On Mon, Sep 16, 2013 at 10:42:11PM -0400, Peter Hurley wrote:
On 09/12/2013 11:38 PM, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock
On Fri, Sep 13, 2013 at 05:55:47AM -0400, Peter Hurley wrote:
> On 09/12/2013 11:44 PM, Greg KH wrote:
> > On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
> >> On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> >>> On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
On 09/12/2013 11:44 PM, Greg KH wrote:
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions
On 09/12/2013 11:44 PM, Greg KH wrote:
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions
On Fri, Sep 13, 2013 at 05:55:47AM -0400, Peter Hurley wrote:
On 09/12/2013 11:44 PM, Greg KH wrote:
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
> On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> > On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> > > Hi Peter,
> > >
> > > FYI, we noticed much increased vmap_area_lock contentions since this
> > > commit:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> > Hi Peter,
> >
> > FYI, we noticed much increased vmap_area_lock contentions since this
> > commit:
>
> What does that mean? What is happening, are we allocating/removing
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> Hi Peter,
>
> FYI, we noticed much increased vmap_area_lock contentions since this
> commit:
What does that mean? What is happening, are we allocating/removing more
memory now?
What type of load were you running that showed this
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley
Date: Sat Jun 15 10:21:19 2013 -0400
n_tty: Move buffers into n_tty_data
Reduce pointer reloading and improve
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley pe...@hurleysoftware.com
Date: Sat Jun 15 10:21:19 2013 -0400
n_tty: Move buffers into n_tty_data
Reduce pointer reloading
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
What does that mean? What is happening, are we allocating/removing more
memory now?
What type of load were you running that showed this
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
What does that mean? What is happening, are we allocating/removing more
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
What does
56 matches
Mail list logo
