On Mon, Feb 02, 2015 at 02:03:33PM -0500, Peter Hurley wrote:
> On 02/02/2015 11:11 AM, Paul E. McKenney wrote:
> > On Tue, Jan 20, 2015 at 09:03:12AM -0500, Peter Hurley wrote:
> >> On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
> >>> On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wro
On 02/02/2015 11:11 AM, Paul E. McKenney wrote:
> On Tue, Jan 20, 2015 at 09:03:12AM -0500, Peter Hurley wrote:
>> On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
>>> On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wrote:
On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
On Tue, Jan 20, 2015 at 09:03:12AM -0500, Peter Hurley wrote:
> On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
> > On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wrote:
> >> On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
> >
> > [ . . . ]
> >
> >> David Miller's call,
On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
> On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wrote:
>> On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
>
> [ . . . ]
>
>> David Miller's call, actually.
>>
>> But the rule is that if it is an atomic read-modify-write op
On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
[ . . . ]
> David Miller's call, actually.
>
> But the rule is that if it is an atomic read-modify-write operation and it
> returns a value, then the operation itself
On 01/16/2015 12:00 PM, Chris Mason wrote:
> On Fri, Jan 16, 2015 at 11:56 AM, Peter Hurley
> wrote:
>> Peter & Kent,
>>
>> What's the plan here?
>
> I'm cleaning up my patch slightly and resubmitting.
Awesome. Will you copy me on it, please?
Regards,
Peter Hurley
--
To unsubscribe from this
On Fri, Jan 16, 2015 at 11:56 AM, Peter Hurley
wrote:
On 01/06/2015 06:07 AM, Kent Overstreet wrote:
On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra
wrote:
On Tue
On 01/06/2015 06:07 AM, Kent Overstreet wrote:
> On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
>>> On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra
>>> wrote:
On Tue, Jan 06, 2015 at 10:57:19AM +0100, Sedat Dile
On Tue, Jan 06, 2015 at 05:28:44AM -0800, Kent Overstreet wrote:
> On Tue, Jan 06, 2015 at 02:03:17PM +0100, Peter Zijlstra wrote:
> > Yeah I got that aspect. I'm still trying to get my head around how the
> > wait_event bit would be a natural match though ;-)
> >
> > Let me stew a bit on that.
>
On Tue, Jan 13, 2015 at 03:33:12AM +, Rik van Riel wrote:
> On 01/09/2015 09:51 PM, David Lang wrote:
> > On Fri, 9 Jan 2015, Linus Torvalds wrote:
> >
> >> Big pages are a bad bad bad idea. They work fine for databases,
> >> and that's pretty much just about it. I'm sure there are some
> >> o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/2015 09:51 PM, David Lang wrote:
> On Fri, 9 Jan 2015, Linus Torvalds wrote:
>
>> Big pages are a bad bad bad idea. They work fine for databases,
>> and that's pretty much just about it. I'm sure there are some
>> other loads, but they are fe
On Mon, Jan 12, 2015 at 07:07:12PM +, Linus Torvalds wrote:
> On Tue, Jan 13, 2015 at 8:06 AM, Linus Torvalds
> wrote:
> >
> > So I'm ok with it, as long as we don't have a performance regression.
> >
> > Your "don't bother freeing when the batch is empty" should hopefully
> > be fine. Dave, d
On Tue, Jan 13, 2015 at 8:06 AM, Linus Torvalds
wrote:
>
> So I'm ok with it, as long as we don't have a performance regression.
>
> Your "don't bother freeing when the batch is empty" should hopefully
> be fine. Dave, does that work for your case?
Oh, and Dave just replied that it's ok. So shoul
On Tue, Jan 13, 2015 at 1:42 AM, Will Deacon wrote:
>
> Linus: this moves the tlb->end check back into tlb_flush_mmu_tlbonly.
> How much do you hate that?
So I'm ok with it, as long as we don't have a performance regression.
Your "don't bother freeing when the batch is empty" should hopefully
be
On 01/12/2015 04:42 AM, Will Deacon wrote:
> Since this effectively reverts f045bbb9fa1b, I've added Dave to Cc. It
> should fix the leak without reintroducing the performance regression.
I ran this on the big system that showed the earlier issue. Everything
seems OK, at least with the test that
On Monday 12 January 2015 14:23:32 Catalin Marinas wrote:
>
> So, I guess it's run-time cost of the LRU algorithm, especially under
> memory pressure. Harder to benchmark though (we'll see when we get
> hardware, though probably not very soon).
One thing you could try is to add an access fault ha
On Mon, Jan 12, 2015 at 01:57:48PM +, Arnd Bergmann wrote:
> On Monday 12 January 2015 12:18:15 Catalin Marinas wrote:
> > On Sat, Jan 10, 2015 at 09:36:13PM +, Arnd Bergmann wrote:
> > > On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
> > > > > IIRC, AIX works great with 64k pag
On Monday 12 January 2015 12:18:15 Catalin Marinas wrote:
> On Sat, Jan 10, 2015 at 09:36:13PM +, Arnd Bergmann wrote:
> > On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
> > > > IIRC, AIX works great with 64k pages, but only because of two
> > > > reasons that don't apply on Linux:
On 01/12/2015 06:42 AM, Will Deacon wrote:
On Sat, Jan 10, 2015 at 07:51:03PM +, Linus Torvalds wrote:
I can revert the commit that causes problems, but considering the
performance impact on x86 (it would be a regression since 3.18), I
would *really* like to fix the arm64 problem instead. So
On Monday 12 January 2015 11:53:42 Catalin Marinas wrote:
> On Sat, Jan 10, 2015 at 08:16:02PM +, Arnd Bergmann wrote:
> > Regarding ARM64 in particular, I think it would be nice to investigate
> > how to extend the THP code to cover 64KB TLBs when running with the 4KB
> > page size. There is a
On Sat, Jan 10, 2015 at 07:51:03PM +, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 5:37 AM, Will Deacon wrote:
> >>
> >> Will?
> >
> > I'm wondering if this is now broken in the fullmm case, because tlb->end
> > will be zero and we won't actually free any of the pages being unmapped
> > on
On Sat, Jan 10, 2015 at 09:36:13PM +, Arnd Bergmann wrote:
> On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
> > > IIRC, AIX works great with 64k pages, but only because of two
> > > reasons that don't apply on Linux:
> >
> > .. there's a few other ones:
> >
> > (c) nobody really
On Sat, Jan 10, 2015 at 08:16:02PM +, Arnd Bergmann wrote:
> Regarding ARM64 in particular, I think it would be nice to investigate
> how to extend the THP code to cover 64KB TLBs when running with the 4KB
> page size. There is a hint bit in the page table to tell the CPU that
> a set of 16 ali
On Sat, Jan 10, 2015 at 10:36:13PM +0100, Arnd Bergmann wrote:
> On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
> > so I feel pretty confident in saying it won't happen. It's just too
> > much of a bother, for little to no actual upside. It's likely a much
> > better approach to try to
On Sat, Jan 10, 2015 at 1:36 PM, Arnd Bergmann wrote:
>>
>> (d) the powerpc TLB fill/buildup/teardown costs are horrible, so on
>> AIX the cost of lots of small pages is much higher too.
>
> I think (d) applies to ARM as well, since it has no hardware
> dirty/referenced bit tracking and requires
On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
>
> > IIRC, AIX works great with 64k pages, but only because of two
> > reasons that don't apply on Linux:
>
> .. there's a few other ones:
>
> (c) nobody really runs AIX on dekstops. It's very much a DB load
> environment, with histori
On Sat, Jan 10, 2015 at 12:16 PM, Arnd Bergmann wrote:
>
> On a recent kernel, I get 628 MB for storing all files of the
> kernel tree in 4KB pages, and 3141 MB for storing the same data
> in 64KB pages, almost exactly factor 5, or 2.45 GiB wasted.
Ok, so it's even worse than it used to be. Part
On Friday 09 January 2015 18:27:38 Linus Torvalds wrote:
> On Fri, Jan 9, 2015 at 4:35 PM, Kirill A. Shutemov
> wrote:
> >
> > With bigger page size there's also reduction in number of entities to
> > handle by kernel: less memory occupied by struct pages, fewer pages on
> > lru, etc.
>
> Really
On 01/10/15 20:56, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 11:47 AM, Laszlo Ersek wrote:
>>
>> I grepped the tree for "fullmm", and only tlb_gather_mmu() seems to set
>> it. There are several instances of that function, but each sets fullmm to:
>>
>> /* Is it from 0 to ~0? */
>>
On Sat, Jan 10, 2015 at 11:47 AM, Laszlo Ersek wrote:
>
> I grepped the tree for "fullmm", and only tlb_gather_mmu() seems to set
> it. There are several instances of that function, but each sets fullmm to:
>
> /* Is it from 0 to ~0? */
> tlb->fullmm = !(start | (end+1));
>
> S
On Sat, Jan 10, 2015 at 5:37 AM, Will Deacon wrote:
>>
>> Will?
>
> I'm wondering if this is now broken in the fullmm case, because tlb->end
> will be zero and we won't actually free any of the pages being unmapped
> on task exit. Does that sound plausible?
But did anything change wrt fullmm? I d
On 01/10/15 14:37, Will Deacon wrote:
> My hunch is that when a task exits and sets fullmm, end is zero and so the
> old need_flush cases no longer run.
(Disclaimer: I'm completely unfamiliar with this code.)
If you have the following call chain in mind:
exit_mmap()
tlb_gather_mmu()
then
On Sat, Jan 10, 2015 at 2:46 AM, Andreas Mohr wrote:
>
> Yet that is what any VirtualAlloc() call on Windows does
> One thing less left to wonder why 'doze is such a performance pig...
Well, to be fair, you shouldn't use VirtualAlloc() as some 'malloc()'
replacement. It's more of a backing store
On Sat, Jan 10, 2015 at 04:29:39AM +0100, Laszlo Ersek wrote:
> I've bisected this issue to
>
Awesome, this was on my list of list of suspicious commits to check
before my ARM64 box decided not to come back from reboot on Friday. :)
Thanks for bisecting!
cheers,
--Kyle
> > f045bbb9fa1bf6f507ad
Hi Linus, Laszlo,
On Sat, Jan 10, 2015 at 04:39:05AM +, Linus Torvalds wrote:
> On Fri, Jan 9, 2015 at 7:29 PM, Laszlo Ersek wrote:
> > I've bisected this issue to
Thanks for bisecting this!
> .. commit f045bbb9fa1b ("mmu_gather: fix over-eager
> tlb_flush_mmu_free() calling")
>
> Hmm. Tha
Linus Torvalds wrote:
> I dunno. I do know that you definitely don't want to haev a
> desktop/workstation with 64kB pages.
Yet that is what any VirtualAlloc() call on Windows does
(well, not exactly *page* granularity but *allocation* granularity there).
Prime example: do a naively specific/custom
On Fri, Jan 9, 2015 at 7:29 PM, Laszlo Ersek wrote:
>
> I've bisected this issue to
.. commit f045bbb9fa1b ("mmu_gather: fix over-eager
tlb_flush_mmu_free() calling")
Hmm. That commit literally just undoes something that commit
fb7332a9fedf ("mmu_gather: move minimal range calculations into
gene
ucer,
and then reboot the known good distro kernel for building the next step
in the bisection.
As reproducer I used "./mallocstress -t 300" (recommended by Mark
Langsdorf & Kyle McMartin, but also named by Will just above this
thread).
One thing I noticed during the several repro turn
On Fri, Jan 9, 2015 at 6:27 PM, Linus Torvalds
wrote:
> Big pages are a bad bad bad idea. They work fine for databases, and
> that's pretty much just about it. I'm sure there are some other loads,
> but they are few and far between.
For HPC too. They tend not to do a lot of I/O (and when they do
On Fri, Jan 9, 2015 at 6:51 PM, David Lang wrote:
>
> what about a dedicated virtualization host (where your workload is a handful
> of virtual machines), would the file cache issue still be overwelming, even
> though it's the virtual machines accessing things?
How much filesystem caches does the
On Fri, 9 Jan 2015, Linus Torvalds wrote:
Big pages are a bad bad bad idea. They work fine for databases, and
that's pretty much just about it. I'm sure there are some other loads,
but they are few and far between.
what about a dedicated virtualization host (where your workload is a handful of
On Fri, Jan 9, 2015 at 4:35 PM, Kirill A. Shutemov wrote:
>
> With bigger page size there's also reduction in number of entities to
> handle by kernel: less memory occupied by struct pages, fewer pages on
> lru, etc.
Bah. Humbug. You've been listening to HW people too much, but they see
the small
On Fri, Jan 09, 2015 at 11:27:07PM +, Catalin Marinas wrote:
> On Thu, Jan 08, 2015 at 07:21:02PM +, Linus Torvalds wrote:
> > The only excuse for 64kB pages is "my hardware TLB is complete crap,
> > and I have very specialized server-only loads".
>
> I would make a slight correction: s/an
On Thu, Jan 08, 2015 at 07:21:02PM +, Linus Torvalds wrote:
> The only excuse for 64kB pages is "my hardware TLB is complete crap,
> and I have very specialized server-only loads".
I would make a slight correction: s/and/or/.
I agree that for a general purpose system (and even systems like we
On Fri, Jan 09, 2015 at 06:37:36PM +, Marc Zyngier wrote:
> On 09/01/15 17:57, Mark Rutland wrote:
> > On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
> >> On 01/09/2015 08:19 AM, Steve Capper wrote:
> >>> On 9 January 2015 at 12:13, Mark Rutland wrote:
> On Thu, Jan 08, 2
On 09/01/15 17:57, Mark Rutland wrote:
> On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
>> On 01/09/2015 08:19 AM, Steve Capper wrote:
>>> On 9 January 2015 at 12:13, Mark Rutland wrote:
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
> I'm consistently ge
On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
> On 01/09/2015 08:19 AM, Steve Capper wrote:
> > On 9 January 2015 at 12:13, Mark Rutland wrote:
> >> On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
> >>> I'm consistently getting an out of memory killer triggered wh
On Thu 08-01-15 10:37:50, Mark Langsdorf wrote:
> On 01/08/2015 09:08 AM, Michal Hocko wrote:
> >[CCing linux-mm and CMA people]
> >[Full message here:
> >http://article.gmane.org/gmane.linux.ports.arm.kernel/383669]
>
> >>[ 1054.095277] DMA: 109*64kB (UR) 53*128kB (R) 8*256kB (R) 0*512kB 0*1024kB
On 01/09/2015 08:19 AM, Steve Capper wrote:
On 9 January 2015 at 12:13, Mark Rutland wrote:
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
I'm consistently getting an out of memory killer triggered when
compiling the kernel (make -j 16 -s) on a 16 core ARM64 system
with 16 GB
On 9 January 2015 at 12:13, Mark Rutland wrote:
> On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
>> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
>> > It's a day delayed - not because of any particular development issues,
>> > but simply because I was tiling a bathroom yesterday.
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
> > It's a day delayed - not because of any particular development issues,
> > but simply because I was tiling a bathroom yesterday. But rc3 is out
> > there now, and things have stayed r
On Thu, Jan 8, 2015 at 10:48 AM, Mark Langsdorf wrote:
>
> With 4K pages, the oom killer doesn't trigger during `make -j 16 -s`
> on a fresh kernel. Thanks for the suggestion. I'm not sure what to do
> about that, though.
I suspect that bisecting remains the best option.
A 64kB allocation will m
On 01/08/2015 11:34 AM, Catalin Marinas wrote:
On Thu, Jan 08, 2015 at 05:29:40PM +, Mark Langsdorf wrote:
On 01/08/2015 07:45 AM, Catalin Marinas wrote:
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
On 01/05/2015 07:46 PM, Linus Torvalds wrote:
It's a day delayed - not
On Thu, Jan 08, 2015 at 05:29:40PM +, Mark Langsdorf wrote:
> On 01/08/2015 07:45 AM, Catalin Marinas wrote:
> > On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
> >> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
> >>> It's a day delayed - not because of any particular developmen
On 01/08/2015 07:45 AM, Catalin Marinas wrote:
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
On 01/05/2015 07:46 PM, Linus Torvalds wrote:
It's a day delayed - not because of any particular development issues,
but simply because I was tiling a bathroom yesterday. But rc3 is ou
On 01/08/2015 09:08 AM, Michal Hocko wrote:
[CCing linux-mm and CMA people]
[Full message here:
http://article.gmane.org/gmane.linux.ports.arm.kernel/383669]
[ 1054.095277] DMA: 109*64kB (UR) 53*128kB (R) 8*256kB (R) 0*512kB 0*1024kB
0*2048kB 1*4096kB (R) 0*8192kB 0*16384kB 1*32768kB (R) 0*655
[CCing linux-mm and CMA people]
[Full message here:
http://article.gmane.org/gmane.linux.ports.arm.kernel/383669]
On Thu 08-01-15 06:51:31, Mark Langsdorf wrote:
[...]
> [ 1053.968815] active_anon:207417 inactive_anon:25722 isolated_anon:0
> [ 1053.968815] active_file:1300 inactive_file:21234 iso
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
> > It's a day delayed - not because of any particular development issues,
> > but simply because I was tiling a bathroom yesterday. But rc3 is out
> > there now, and things have stayed r
On 01/05/2015 07:46 PM, Linus Torvalds wrote:
It's a day delayed - not because of any particular development issues,
but simply because I was tiling a bathroom yesterday. But rc3 is out
there now, and things have stayed reasonably calm. I really hope that
implies that 3.19 is looking good, but it
On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
> On 01/06/2015 02:25 PM, Paul E. McKenney wrote:
> > On Tue, Jan 06, 2015 at 12:58:36PM -0500, Peter Hurley wrote:
> >> On 01/06/2015 12:38 PM, Paul E. McKenney wrote:
> >>> On Tue, Jan 06, 2015 at 07:55:39AM -0500, Peter Hurley wrote:
On 01/06/2015 02:25 PM, Paul E. McKenney wrote:
> On Tue, Jan 06, 2015 at 12:58:36PM -0500, Peter Hurley wrote:
>> On 01/06/2015 12:38 PM, Paul E. McKenney wrote:
>>> On Tue, Jan 06, 2015 at 07:55:39AM -0500, Peter Hurley wrote:
[ +cc Paul McKenney ]
On 01/06/2015 07:20 AM, Peter Zij
On Tue, Jan 06, 2015 at 12:58:36PM -0500, Peter Hurley wrote:
> On 01/06/2015 12:38 PM, Paul E. McKenney wrote:
> > On Tue, Jan 06, 2015 at 07:55:39AM -0500, Peter Hurley wrote:
> >> [ +cc Paul McKenney ]
> >>
> >> On 01/06/2015 07:20 AM, Peter Zijlstra wrote:
> >>> On Tue, Jan 06, 2015 at 04:01:21
On 01/06/2015 12:38 PM, Paul E. McKenney wrote:
> On Tue, Jan 06, 2015 at 07:55:39AM -0500, Peter Hurley wrote:
>> [ +cc Paul McKenney ]
>>
>> On 01/06/2015 07:20 AM, Peter Zijlstra wrote:
>>> On Tue, Jan 06, 2015 at 04:01:21AM -0800, Kent Overstreet wrote:
On Tue, Jan 06, 2015 at 12:48:42PM +
On Tue, Jan 06, 2015 at 07:55:39AM -0500, Peter Hurley wrote:
> [ +cc Paul McKenney ]
>
> On 01/06/2015 07:20 AM, Peter Zijlstra wrote:
> > On Tue, Jan 06, 2015 at 04:01:21AM -0800, Kent Overstreet wrote:
> >> On Tue, Jan 06, 2015 at 12:48:42PM +0100, Peter Zijlstra wrote:
> >>>
> >>>
> >>> Lookin
On Tue, Jan 06, 2015 at 02:03:17PM +0100, Peter Zijlstra wrote:
> Yeah I got that aspect. I'm still trying to get my head around how the
> wait_event bit would be a natural match though ;-)
>
> Let me stew a bit on that.
Also, I think it was kind of a surprise to me back in the day how structural
On Tue, Jan 06, 2015 at 04:43:13AM -0800, Kent Overstreet wrote:
> It might make the most sense to cook up something new, stealing some of the
> closure code but using standard the wait_queue_head_t - having a single
> standard
> waitlist type is definitely a good thing, and unfortunately I don't
[ +cc Paul McKenney ]
On 01/06/2015 07:20 AM, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 04:01:21AM -0800, Kent Overstreet wrote:
>> On Tue, Jan 06, 2015 at 12:48:42PM +0100, Peter Zijlstra wrote:
>>>
>>>
>>> Looking at that closure stuff, why is there an smp_mb() in
>>> closure_wake_up() ? T
On Tue, Jan 6, 2015 at 12:40 PM, Kent Overstreet wrote:
> On Tue, Jan 06, 2015 at 12:25:39PM +0100, Sedat Dilek wrote:
>> On Tue, Jan 6, 2015 at 12:07 PM, Kent Overstreet wrote:
>> > On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
>> >> On Tue, Jan 06, 2015 at 11:18:04AM +0100, Se
On Tue, Jan 06, 2015 at 01:20:06PM +0100, Peter Zijlstra wrote:
> We (probably me) should probably audit all the atomic_xchg()
> implementations and documentation and fix that. I was very much under
> the impression it should imply a full barrier (and it certainly does on
> x86), the documentation
On Tue, Jan 06, 2015 at 01:16:03PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 03:56:45AM -0800, Kent Overstreet wrote:
> > I do want to make the point that it's not really the callers that are
> > broken;
> > especially those that are using prepare_to_wait() via wait_event(). Using
> >
On Tue, Jan 06, 2015 at 04:01:21AM -0800, Kent Overstreet wrote:
> On Tue, Jan 06, 2015 at 12:48:42PM +0100, Peter Zijlstra wrote:
> >
> >
> > Looking at that closure stuff, why is there an smp_mb() in
> > closure_wake_up() ? Typically wakeup only needs to imply a wmb.
> >
> > Also note that __c
On Tue, Jan 06, 2015 at 03:56:45AM -0800, Kent Overstreet wrote:
> I do want to make the point that it's not really the callers that are broken;
> especially those that are using prepare_to_wait() via wait_event(). Using
> wait_event() is exactly what people _should_ be doing, instead of open codin
On Tue, Jan 06, 2015 at 12:58:22PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 03:07:30AM -0800, Kent Overstreet wrote:
> > http://evilpiepirate.org/git/linux-bcache.git/log/?h=aio_ring_fix
>
> Very terse changelogs there :/
erg, I've been slacking on changelogs lately. that closure_sy
On Tue, Jan 06, 2015 at 12:48:42PM +0100, Peter Zijlstra wrote:
>
>
> Looking at that closure stuff, why is there an smp_mb() in
> closure_wake_up() ? Typically wakeup only needs to imply a wmb.
>
> Also note that __closure_wake_up() starts with a fully serializing
> instruction (xchg) and there
On Tue, Jan 06, 2015 at 03:07:30AM -0800, Kent Overstreet wrote:
> http://evilpiepirate.org/git/linux-bcache.git/log/?h=aio_ring_fix
Very terse changelogs there :/
Also, I'm not sure I agree with that whole closure_wait_event*() stuff,
the closure interface as it exist before that makes sense, bu
On Tue, Jan 06, 2015 at 12:42:15PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 03:07:30AM -0800, Kent Overstreet wrote:
> > > No, the root cause is nesting sleep primitives, this is not fixable in
> > > the one place, both prepare_to_wait and mutex_lock are using
> > > task_struct::state
Looking at that closure stuff, why is there an smp_mb() in
closure_wake_up() ? Typically wakeup only needs to imply a wmb.
Also note that __closure_wake_up() starts with a fully serializing
instruction (xchg) and thereby already implies the full barrier.
--
To unsubscribe from this list: send
On Tue, Jan 06, 2015 at 03:07:30AM -0800, Kent Overstreet wrote:
> > No, the root cause is nesting sleep primitives, this is not fixable in
> > the one place, both prepare_to_wait and mutex_lock are using
> > task_struct::state, they have to, no way around it.
>
> No, it's completely possible to c
On Tue, Jan 06, 2015 at 12:25:39PM +0100, Sedat Dilek wrote:
> On Tue, Jan 6, 2015 at 12:07 PM, Kent Overstreet wrote:
> > On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
> >> On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
> >> > On Tue, Jan 6, 2015 at 11:06 AM, Peter
On Tue, Jan 6, 2015 at 12:07 PM, Kent Overstreet wrote:
> On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
>> > On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra
>> > wrote:
>> > > On Tue, Jan 06, 2015 at 10:57:19AM +01
On Tue, Jan 06, 2015 at 12:01:12PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
> > On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra
> > wrote:
> > > On Tue, Jan 06, 2015 at 10:57:19AM +0100, Sedat Dilek wrote:
> > >> [ 88.028739] [] aio_read_event
On Tue, Jan 06, 2015 at 11:18:04AM +0100, Sedat Dilek wrote:
> On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra wrote:
> > On Tue, Jan 06, 2015 at 10:57:19AM +0100, Sedat Dilek wrote:
> >> [ 88.028739] [] aio_read_events+0x4f/0x2d0
> >>
> >
> > Ah, that one. Chris Mason and Kent Overstreet were
t;> > It's "check for stack overflow in ___might_sleep".
>> >> >> > Unfortunately, it did not help in case of my loop-mq tests.
>> >> >> > ( BTW, this is touching ___might_sleep() (note: triple-underscore VS.
>> >> >> >
; >> >
> >> >> > - Sedat -
> >> >> >
> >> >> > [1] http://marc.info/?l=linux-aio&m=142033318411355&w=2
> >> >> > [2] http://marc.info/?l=linux-aio&m=142035799514685&w=2
> >> >> > [3] h
t;> >> >
>> >> > [1] http://marc.info/?l=linux-aio&m=142033318411355&w=2
>> >> > [2] http://marc.info/?l=linux-aio&m=142035799514685&w=2
>> >> > [3] http://evilpiepirate.org/git/linux-bcache.git/log/?h=aio_ring_fix
>> &g
On Tue, Jan 6, 2015 at 10:40 AM, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 05:49:11AM +0100, Sedat Dilek wrote:
>> This has been there since just before rc1. Is there a fix for this
>> stalled in someones git tree maybe ?
>>
>> [7.952588] WARNING: CPU: 0 PID: 299 at kernel/sched/core.c:7
>>
> >> >From [1]:
> >> ...
> >>
> >> Just "me too" (but overlooked until recently).
> >>
> >> The cause is a mutex_lock() call right after prepare_to_wait() with
> >> TASK_INTERRUPTIBLE in fanotify_read().
> >
On Tue, Jan 6, 2015 at 11:06 AM, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 10:57:19AM +0100, Sedat Dilek wrote:
>> [ 88.028739] [] aio_read_events+0x4f/0x2d0
>>
>
> Ah, that one. Chris Mason and Kent Overstreet were looking at that one.
> I'm not touching the AIO code either ;-)
I know,
RRUPTIBLE in fanotify_read().
>>
>> static ssize_t fanotify_read(struct file *file, char __user *buf,
>> size_t count, loff_t *pos)
>> {
>>
>> while (1) {
>> prepare_to_wait(&group->notification_waitq, &wait, TASK_INTERRUPTIBLE);
&
On Tue, Jan 06, 2015 at 10:57:19AM +0100, Sedat Dilek wrote:
> [ 88.028739] [] aio_read_events+0x4f/0x2d0
>
Ah, that one. Chris Mason and Kent Overstreet were looking at that one.
I'm not touching the AIO code either ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Tue, Jan 06, 2015 at 10:34:30AM +0100, Sedat Dilek wrote:
> I tried to do such a "similiar" (quick) fix analog to the mentioned
> "sched, inotify: Deal with nested sleeps" patch from Peter.
> If I did correct... It does not make the call-trace go away here.
Are you very sure its the same splat
On Tue, Jan 6, 2015 at 10:42 AM, Sedat Dilek wrote:
> On Tue, Jan 6, 2015 at 10:40 AM, Peter Zijlstra wrote:
>> On Tue, Jan 06, 2015 at 05:49:11AM +0100, Sedat Dilek wrote:
>>> This has been there since just before rc1. Is there a fix for this
>>> stalled in someones git tree maybe ?
>>>
>>> [
At Tue, 6 Jan 2015 10:34:30 +0100,
Sedat Dilek wrote:
>
> On Tue, Jan 6, 2015 at 5:49 AM, Sedat Dilek wrote:
> > [ Please CC me I am not subscribed to LKML ]
> >
> > [ QUOTE ]
> >
> > On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote:
> > > It's a day delayed - not because of any pa
On Mon, 5 Jan 2015, Dave Jones wrote:
> > It's a day delayed - not because of any particular development issues,
> > but simply because I was tiling a bathroom yesterday. But rc3 is out
> > there now, and things have stayed reasonably calm. I really hope that
> > implies that 3.19 is looking g
On Tue, Jan 6, 2015 at 10:40 AM, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 05:49:11AM +0100, Sedat Dilek wrote:
>> This has been there since just before rc1. Is there a fix for this
>> stalled in someones git tree maybe ?
>>
>> [7.952588] WARNING: CPU: 0 PID: 299 at kernel/sched/core.c:7
On Tue, Jan 06, 2015 at 05:49:11AM +0100, Sedat Dilek wrote:
> This has been there since just before rc1. Is there a fix for this
> stalled in someones git tree maybe ?
>
> [7.952588] WARNING: CPU: 0 PID: 299 at kernel/sched/core.c:7303
> __might_sleep+0x8d/0xa0()
> [7.952592] do not call
On Tue, Jan 6, 2015 at 5:49 AM, Sedat Dilek wrote:
> [ Please CC me I am not subscribed to LKML ]
>
> [ QUOTE ]
>
> On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote:
> > It's a day delayed - not because of any particular development issues,
> > but simply because I was tiling a bat
At Mon, 5 Jan 2015 21:46:34 -0500,
Dave Jones wrote:
>
> On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote:
> > It's a day delayed - not because of any particular development issues,
> > but simply because I was tiling a bathroom yesterday. But rc3 is out
> > there now, and things
[ Please CC me I am not subscribed to LKML ]
[ QUOTE ]
On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote:
> It's a day delayed - not because of any particular development issues,
> but simply because I was tiling a bathroom yesterday. But rc3 is out
> there now, and things have st
On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote:
> It's a day delayed - not because of any particular development issues,
> but simply because I was tiling a bathroom yesterday. But rc3 is out
> there now, and things have stayed reasonably calm. I really hope that
> implies that
1 - 100 of 101 matches
Mail list logo
