Hi,
> On Sun, Apr 11, 2021 at 11:20:00PM +0800, Wang Yugui wrote:
> > Hi, Dennis Zhou
> >
> > > Hi,
> > >
> > > > On Sat, Apr 10, 2021 at 11:29:17PM +0800, Wang Yugui wrote:
> > > > > Hi, Dennis Zhou
> > > > >
> > > > > Thanks for your ncie answer.
> > > > > but still a few questions.
> > > >
On Sun, Apr 11, 2021 at 11:20:00PM +0800, Wang Yugui wrote:
> Hi, Dennis Zhou
>
> > Hi,
> >
> > > On Sat, Apr 10, 2021 at 11:29:17PM +0800, Wang Yugui wrote:
> > > > Hi, Dennis Zhou
> > > >
> > > > Thanks for your ncie answer.
> > > > but still a few questions.
> > > >
> > > > > Percpu is not
Hi, Dennis Zhou
> Hi,
>
> > On Sat, Apr 10, 2021 at 11:29:17PM +0800, Wang Yugui wrote:
> > > Hi, Dennis Zhou
> > >
> > > Thanks for your ncie answer.
> > > but still a few questions.
> > >
> > > > Percpu is not really cheap memory to allocate because it has a
> > > > amplification factor of N
Hi,
> On Sat, Apr 10, 2021 at 11:29:17PM +0800, Wang Yugui wrote:
> > Hi, Dennis Zhou
> >
> > Thanks for your ncie answer.
> > but still a few questions.
> >
> > > Percpu is not really cheap memory to allocate because it has a
> > > amplification factor of NR_CPUS. As a result, percpu on the cr
On Sat, Apr 10, 2021 at 11:29:17PM +0800, Wang Yugui wrote:
> Hi, Dennis Zhou
>
> Thanks for your ncie answer.
> but still a few questions.
>
> > Percpu is not really cheap memory to allocate because it has a
> > amplification factor of NR_CPUS. As a result, percpu on the critical
> > path is re
Hi, Dennis Zhou
Thanks for your ncie answer.
but still a few questions.
> Percpu is not really cheap memory to allocate because it has a
> amplification factor of NR_CPUS. As a result, percpu on the critical
> path is really not something that is expected to be high throughput.
> Ideally things
On Fri, Apr 09, 2021 at 03:36:39PM +0800, Wang Yugui wrote:
> Hi,
>
> some question about workqueue for percpu.
>
> > > >
> > > > And a question about this,
> > > > > > > > upper caller:
> > > > > > > > nofs_flag = memalloc_nofs_save();
> > > > > > > > ret = btrfs_drew_lock_init(&root->s
On Fri, Apr 9, 2021 at 2:39 PM Dennis Zhou wrote:
>
> On Fri, Apr 09, 2021 at 12:39:38PM +0100, Filipe Manana wrote:
> > On Thu, Apr 8, 2021 at 4:02 PM Dennis Zhou wrote:
> > >
> > > On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> > > > On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou
On Fri, Apr 09, 2021 at 12:39:38PM +0100, Filipe Manana wrote:
> On Thu, Apr 8, 2021 at 4:02 PM Dennis Zhou wrote:
> >
> > On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> > > On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
> > > >
> > > > On Thu, Apr 08, 2021 at 05:20:00PM +080
On Thu, Apr 8, 2021 at 4:02 PM Dennis Zhou wrote:
>
> On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> > On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
> > >
> > > On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> > > > Hi,
> > > >
> > > > > On Thu, Apr 08, 2021 at
Hi, Dennis Zhou, Vlastimil Babka, Filipe Manana
The root reason of this problem maybe the design of
'memalloc_nofs_restore()/memalloc_nofs_save()'.
When some job such as memory pre-alloc and reclaim is needed, that is
done in a workqueue now.
This is a problem for high-load and over-load. In th
Hi,
Add top/free info when our applicaiton pipeline is running.
> Hi,
>
> some question about workqueue for percpu.
>
> > > >
> > > > And a question about this,
> > > > > > > > upper caller:
> > > > > > > > nofs_flag = memalloc_nofs_save();
> > > > > > > > ret = btrfs_drew_lock_init(&r
Hi,
some question about workqueue for percpu.
> > >
> > > And a question about this,
> > > > > > > upper caller:
> > > > > > > nofs_flag = memalloc_nofs_save();
> > > > > > > ret = btrfs_drew_lock_init(&root->snapshot_lock);
> > > > > > > memalloc_nofs_restore(nofs_flag);
> > > >
>
Hi,
> On Fri, Apr 09, 2021 at 08:08:00AM +0800, Wang Yugui wrote:
> > Hi,
> >
> > > > kernel: at least 5.10.26/5.10.27/5.10.28
> > > >
> > > > This problem is triggered by our application, NOT xfstests.
> > > > But our applicaiton have some heavy write load just like
> > > > xfstest/generic/476
On Fri, Apr 09, 2021 at 08:08:00AM +0800, Wang Yugui wrote:
> Hi,
>
> > > kernel: at least 5.10.26/5.10.27/5.10.28
> > >
> > > This problem is triggered by our application, NOT xfstests.
> > > But our applicaiton have some heavy write load just like
> > > xfstest/generic/476.
> > > Our applicati
Hi,
> > kernel: at least 5.10.26/5.10.27/5.10.28
> >
> > This problem is triggered by our application, NOT xfstests.
> > But our applicaiton have some heavy write load just like
> > xfstest/generic/476.
> > Our application use at most 75% of memory, if still not enough,
> > it will write out al
On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
> >
> > On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> > > Hi,
> > >
> > > > On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> > > > > Hi,
> > > > >
> > > >
On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
>
> On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> > Hi,
> >
> > > On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> > > > Hi,
> > > >
> > > > > > > > upper caller:
> > > > > > > > nofs_flag = memalloc_nofs_save();
>
On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> Hi,
>
> > On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> > > Hi,
> > >
> > > > > > > upper caller:
> > > > > > > nofs_flag = memalloc_nofs_save();
> > > > > > > ret = btrfs_drew_lock_init(&root->snapshot_lock);
>
Hi,
> On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> > Hi,
> >
> > > > > > upper caller:
> > > > > > nofs_flag = memalloc_nofs_save();
> > > > > > ret = btrfs_drew_lock_init(&root->snapshot_lock);
> > > > > > memalloc_nofs_restore(nofs_flag);
> > >
> > > The issue is h
On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> Hi,
>
> > > > > upper caller:
> > > > > nofs_flag = memalloc_nofs_save();
> > > > > ret = btrfs_drew_lock_init(&root->snapshot_lock);
> > > > > memalloc_nofs_restore(nofs_flag);
> >
> > The issue is here. nofs is set which
Hi,
> > > > upper caller:
> > > > nofs_flag = memalloc_nofs_save();
> > > > ret = btrfs_drew_lock_init(&root->snapshot_lock);
> > > > memalloc_nofs_restore(nofs_flag);
>
> The issue is here. nofs is set which means percpu attempts an atomic
> allocation. If it cannot find anything alr
Hello,
On Wed, Apr 07, 2021 at 09:09:07PM +0800, Wang Yugui wrote:
> Hi,
>
> > +CC btrfs
> >
> > On 4/1/21 12:51 PM, Wang Yugui wrote:
> > > Hi,
> > >
> > > an unexpected -ENOMEM from percpu_counter_init() happened when xfstest
> > > with kernel 5.11.10 and 5.10.27
> >
> > Is there a dmesg lo
Hi,
> +CC btrfs
>
> On 4/1/21 12:51 PM, Wang Yugui wrote:
> > Hi,
> >
> > an unexpected -ENOMEM from percpu_counter_init() happened when xfstest
> > with kernel 5.11.10 and 5.10.27
>
> Is there a dmesg log showing allocation failure or something?
When unexpected -ENOMEM of percpu_counter_init
+CC btrfs
On 4/1/21 12:51 PM, Wang Yugui wrote:
> Hi,
>
> an unexpected -ENOMEM from percpu_counter_init() happened when xfstest
> with kernel 5.11.10 and 5.10.27
Is there a dmesg log showing allocation failure or something?
> direct caller:
> int btrfs_drew_lock_init(struct btrfs_drew_lock *l
25 matches
Mail list logo
