CC-ing sta...@vger.kernel.org and adding some more explanations.
On Tue, 5 May 2020 10:10:33 +0200 SeongJae Park wrote:
> From: SeongJae Park
>
> The commit 6d7855c54e1e ("sockfs: switch to ->free_inode()") made the
> deallocation of 'socket_alloc' to be done asynchronously using RCU, as
> sam
On Tue, 2020-05-05 at 13:54 +0200, SeongJae Park wrote:
> CC-ing sta...@vger.kernel.org and adding some more explanations.
>
> On Tue, 5 May 2020 10:10:33 +0200 SeongJae Park
> wrote:
>
> >
> > From: SeongJae Park
> >
> > The commit 6d7855c54e1e ("sockfs: switch to ->free_inode()") made
> > t
On Tue, May 5, 2020 at 4:54 AM SeongJae Park wrote:
>
> CC-ing sta...@vger.kernel.org and adding some more explanations.
>
> On Tue, 5 May 2020 10:10:33 +0200 SeongJae Park wrote:
>
> > From: SeongJae Park
> >
> > The commit 6d7855c54e1e ("sockfs: switch to ->free_inode()") made the
> > dealloca
On 5/5/20 8:07 AM, SeongJae Park wrote:
> On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet wrote:
>
>> Why do we have 10,000,000 objects around ? Could this be because of
>> some RCU problem ?
>
> Mainly because of a long RCU grace period, as you guess. I have no idea how
> the grace period b
On 5/5/20 9:13 AM, SeongJae Park wrote:
> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>
>> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>>>
>>> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
>>> wrote:
>>>
On 5/5/20 8:07 AM, SeongJae Park wrote:
> On Tue,
On 5/5/20 9:25 AM, Eric Dumazet wrote:
>
>
> On 5/5/20 9:13 AM, SeongJae Park wrote:
>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>>
>>> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
wrote:
>
>
>>>
On 5/5/20 9:31 AM, Eric Dumazet wrote:
>
>
> On 5/5/20 9:25 AM, Eric Dumazet wrote:
>>
>>
>> On 5/5/20 9:13 AM, SeongJae Park wrote:
>>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>>>
On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>
> On Tue, 5 May 2020 08:20:50
On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
>
>
> On 5/5/20 9:13 AM, SeongJae Park wrote:
> > On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
> >
> >> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
> >>>
> >>> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
> >>>
On Tue, May 05, 2020 at 09:37:42AM -0700, Eric Dumazet wrote:
>
>
> On 5/5/20 9:31 AM, Eric Dumazet wrote:
> >
> >
> > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> >>
> >>
> >> On 5/5/20 9:13 AM, SeongJae Park wrote:
> >>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet
> >>> wrote:
> >>>
> O
From: SeongJae Park
Date: Tue, 5 May 2020 10:10:33 +0200
> From: SeongJae Park
>
> The commit 6d7855c54e1e ("sockfs: switch to ->free_inode()") made the
> deallocation of 'socket_alloc' to be done asynchronously using RCU, as
> same to 'sock.wq'. And the following commit 333f7909a857 ("coalloc
From: David Miller
Date: Tue, 05 May 2020 11:48:25 -0700 (PDT)
> Series applied and queued up for -stable, thanks.
Nevermind, this doesn't even compile.
net/smc/af_smc.c: In function ‘smc_switch_to_fallback’:
net/smc/af_smc.c:473:19: error: ‘smc->clcsock->wq’ is a pointer; did you mean
to use
On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet wrote:
> On Tue, May 5, 2020 at 4:54 AM SeongJae Park wrote:
> >
> > CC-ing sta...@vger.kernel.org and adding some more explanations.
> >
> > On Tue, 5 May 2020 10:10:33 +0200 SeongJae Park wrote:
> >
> > > From: SeongJae Park
> > >
> > > The comm
On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet wrote:
>
>
> On 5/5/20 8:07 AM, SeongJae Park wrote:
> > On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet wrote:
> >
>
> >> Why do we have 10,000,000 objects around ? Could this be because of
> >> some RCU problem ?
> >
> > Mainly because of a lo
On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>
> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet wrote:
>
> >
> >
> > On 5/5/20 8:07 AM, SeongJae Park wrote:
> > > On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet
> > > wrote:
> > >
> >
> > >> Why do we have 10,000,000 objects around ? Could
On Tue, May 05, 2020 at 09:00:44AM -0700, Eric Dumazet wrote:
> > Not exactly the 10,000,000, as it is only the possible highest number, but I
> > was able to observe clear exponential increase of the number of the objects
> > using slabtop. Before the start of the problematic workload, the numbe
On Tue, 5 May 2020 09:37:42 -0700 Eric Dumazet wrote:
>
>
> On 5/5/20 9:31 AM, Eric Dumazet wrote:
> >
> >
> > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> >>
> >>
> >> On 5/5/20 9:13 AM, SeongJae Park wrote:
> >>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet
> >>> wrote:
> >>>
> On Tue,
On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 09:37:42 -0700 Eric Dumazet wrote:
>
> >
> >
> > On 5/5/20 9:31 AM, Eric Dumazet wrote:
> > >
> > >
> > > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> > >>
> > >>
> > >> On 5/5/20 9:13 AM, SeongJae Park wrote:
> >
On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenney" wrote:
> On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
> >
> >
> > On 5/5/20 9:13 AM, SeongJae Park wrote:
> > > On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet
> > > wrote:
> > >
> > >> On Tue, May 5, 2020 at 8:47 AM SeongJ
On Tue, 5 May 2020 10:28:50 -0700 "Paul E. McKenney" wrote:
> On Tue, May 05, 2020 at 09:37:42AM -0700, Eric Dumazet wrote:
> >
> >
> > On 5/5/20 9:31 AM, Eric Dumazet wrote:
> > >
> > >
> > > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> > >>
> > >>
> > >> On 5/5/20 9:13 AM, SeongJae Park wrote:
On Tue, May 05, 2020 at 07:49:43PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
> > >
> > >
> > > On 5/5/20 9:13 AM, SeongJae Park wrote:
> > > > On Tue, 5 May 2020 09:00:44 -0700
On Tue, 05 May 2020 12:00:49 -0700 (PDT) David Miller
wrote:
> From: David Miller
> Date: Tue, 05 May 2020 11:48:25 -0700 (PDT)
>
> > Series applied and queued up for -stable, thanks.
>
> Nevermind, this doesn't even compile.
>
> net/smc/af_smc.c: In function ‘smc_switch_to_fallback’:
> net/
On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
> >
> > On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
> > wrote:
> >
> > >
> > >
> > > On 5/5/20 8:07 AM, SeongJae Park wrote:
> > > > On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet
>
On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenney" wrote:
> On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> > On Tue, 5 May 2020 09:37:42 -0700 Eric Dumazet
> > wrote:
> >
> > >
> > >
> > > On 5/5/20 9:31 AM, Eric Dumazet wrote:
> > > >
> > > >
> > > > On 5/5/20 9:25 AM,
On Tue, May 05, 2020 at 07:56:05PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 09:37:42 -0700 Eric Dumazet
> > > wrote:
> > >
> > > >
> > > >
> > > >
On Tue, 5 May 2020 11:27:20 -0700 "Paul E. McKenney" wrote:
> On Tue, May 05, 2020 at 07:49:43PM +0200, SeongJae Park wrote:
> > On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenney"
> > wrote:
> >
> > > On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
> > > >
> > > >
> > > > On
On Tue, May 05, 2020 at 08:40:07PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 11:27:20 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:49:43PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenney"
> > > wrote:
> > >
> > > > On Tue, May
On Tue, 5 May 2020 11:17:07 -0700 "Paul E. McKenney" wrote:
> On Tue, May 05, 2020 at 07:56:05PM +0200, SeongJae Park wrote:
> > On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenney"
> > wrote:
> >
> > > On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> > > > On Tue, 5 May 2020 0
On Tue, May 05, 2020 at 08:34:02PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 11:17:07 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:56:05PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenney"
> > > wrote:
> > >
> > > > On Tue, May
TL; DR: It was not kernel's fault, but the benchmark program.
So, the problem is reproducible using the lebench[1] only. I carefully read
it's code again.
Before running the problem occurred "poll big" sub test, lebench executes
"context switch" sub test. For the test, it sets the cpu affinity[
On Wed, May 6, 2020 at 5:59 AM SeongJae Park wrote:
>
> TL; DR: It was not kernel's fault, but the benchmark program.
>
> So, the problem is reproducible using the lebench[1] only. I carefully read
> it's code again.
>
> Before running the problem occurred "poll big" sub test, lebench executes
>
On Wed, May 06, 2020 at 02:59:26PM +0200, SeongJae Park wrote:
> TL; DR: It was not kernel's fault, but the benchmark program.
>
> So, the problem is reproducible using the lebench[1] only. I carefully read
> it's code again.
>
> Before running the problem occurred "poll big" sub test, lebench e
On Wed, 6 May 2020 07:41:51 -0700 "Paul E. McKenney" wrote:
> On Wed, May 06, 2020 at 02:59:26PM +0200, SeongJae Park wrote:
> > TL; DR: It was not kernel's fault, but the benchmark program.
> >
> > So, the problem is reproducible using the lebench[1] only. I carefully read
> > it's code again.
32 matches
Mail list logo