[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1490973609.2587.3.camel@sandisk.com>
Date: Fri, 31 Mar 2017 15:20:29 +0000
From: Bart Van Assche <Bart.VanAssche@...disk.com>
To: "tj@...nel.org" <tj@...nel.org>,
"paolo.valente@...aro.org" <paolo.valente@...aro.org>,
"axboe@...nel.dk" <axboe@...nel.dk>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"samuele.zecchini92@...il.com" <samuele.zecchini92@...il.com>,
"fchecconi@...il.com" <fchecconi@...il.com>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"avanzini.arianna@...il.com" <avanzini.arianna@...il.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"riccardo.pizzetti@...il.com" <riccardo.pizzetti@...il.com>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>
Subject: Re: [PATCH V2 11/16] block, bfq: reduce idling only in symmetric
scenarios
On Fri, 2017-03-31 at 14:47 +0200, Paolo Valente wrote:
> + entity->weight_counter = kzalloc(sizeof(struct bfq_weight_counter),
> + GFP_ATOMIC);
> + entity->weight_counter->weight = entity->weight;
GFP_ATOMIC allocations are more likely to fail than GFP_KERNEL allocations.
What will happen if kzalloc() returns NULL?
Bart.
Powered by blists - more mailing lists