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, page-or-less
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 the
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 definit
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.
So
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 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
> >wrote:
> >
> >>Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> >>could definitely be reduced (even near
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
com
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 ("n_tt
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
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 (e
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 (even
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 loo
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 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 201
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
co
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 20bafb
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 201
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_are
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, a
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 since
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 m
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 pr
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 locality-of-re
28 matches
Mail list logo
