On 09/12/2019 03:09 PM, André Almeida wrote:
> Hello Matthew,
>
> On 9/12/19 1:19 PM, Matthew Wilcox wrote:
>> On Wed, Sep 11, 2019 at 11:46:36AM -0300, André Almeida wrote:
>>>
>>> -static int nr_devices = 1;
>>> +static unsigned int nr_devices = 1;
>>> module_param(nr_devices, int, 0444);
>>
>>
On 9/12/19 5:47 PM, Jens Axboe wrote:
> On 9/12/19 9:47 AM, Ezequiel Garcia wrote:
>> Hi André, Jens,
>>
>> On Wed, 2019-09-11 at 11:46 -0300, André Almeida wrote:
>>> The name of the module is "null_blk", not "null". Make `pr_info()` follow
>>> the pattern of `pr_err()` log messages.
>>>
>>
>> Ins
Hello Matthew,
On 9/12/19 1:19 PM, Matthew Wilcox wrote:
> On Wed, Sep 11, 2019 at 11:46:36AM -0300, André Almeida wrote:
>>
>> -static int nr_devices = 1;
>> +static unsigned int nr_devices = 1;
>> module_param(nr_devices, int, 0444);
>
> ^^^ you forgot to change the module_param to match
>
On 9/12/19 9:47 AM, Ezequiel Garcia wrote:
> Hi André, Jens,
>
> On Wed, 2019-09-11 at 11:46 -0300, André Almeida wrote:
>> The name of the module is "null_blk", not "null". Make `pr_info()` follow
>> the pattern of `pr_err()` log messages.
>>
>
> Instead of doing these fixes manually, it's more
On 9/12/19 2:13 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> We currently merge async work items if we see a strict sequential hit.
>> This helps avoid unnecessary workqueue switches when we don't need
>> them. We can extend this merging to cover cases where it's not a strict
>> sequential hit
Jens Axboe writes:
> The way the logic is setup in io_uring_enter() means that you can't wake
> up the SQ poller thread while at the same time waiting (or polling) for
> completions afterwards. There's no reason for that to be the case.
>
> Reported-by: Lewis Baker
> Signed-off-by: Jens Axboe
Jens Axboe writes:
> We currently merge async work items if we see a strict sequential hit.
> This helps avoid unnecessary workqueue switches when we don't need
> them. We can extend this merging to cover cases where it's not a strict
> sequential hit, but the IO still fits within the same page.
On 9/12/19 10:41 AM, Sagi Grimberg wrote:
> Hey Jens,
>
> This is the second batch of nvme updates for 5.4.
>
> Highlights includes:
> - controller reset and namespace scan races fixes
> - nvme discovery log change uevent support
> - naming improvements from Keith
> - multiple discovery controlle
Hey Jens,
This is the second batch of nvme updates for 5.4.
Highlights includes:
- controller reset and namespace scan races fixes
- nvme discovery log change uevent support
- naming improvements from Keith
- multiple discovery controllers reject fix from James
- some regular cleanups from variou
On 09/12/2019 11:22 AM, Mike Christie wrote:
> On 09/11/2019 02:21 PM, Martin Raiber wrote:
>> On 11.09.2019 18:56 Mike Christie wrote:
>>> On 09/11/2019 03:40 AM, Martin Raiber wrote:
On 10.09.2019 10:35 Damien Le Moal wrote:
> Mike,
>
> On 2019/09/09 19:26, Mike Christie wrote:
>
On 09/11/2019 02:21 PM, Martin Raiber wrote:
> On 11.09.2019 18:56 Mike Christie wrote:
>> On 09/11/2019 03:40 AM, Martin Raiber wrote:
>>> On 10.09.2019 10:35 Damien Le Moal wrote:
Mike,
On 2019/09/09 19:26, Mike Christie wrote:
> Forgot to cc linux-mm.
>
> On 09/09/2019
On Wed, Sep 11, 2019 at 11:46:36AM -0300, André Almeida wrote:
>
> -static int nr_devices = 1;
> +static unsigned int nr_devices = 1;
> module_param(nr_devices, int, 0444);
^^^ you forgot to change the module_param to match
> + if (!nr_devices) {
> + pr_err("null_blk: invalid n
The way the logic is setup in io_uring_enter() means that you can't wake
up the SQ poller thread while at the same time waiting (or polling) for
completions afterwards. There's no reason for that to be the case.
Reported-by: Lewis Baker
Signed-off-by: Jens Axboe
--
diff --git a/fs/io_uring.c b
Hi André, Jens,
On Wed, 2019-09-11 at 11:46 -0300, André Almeida wrote:
> The name of the module is "null_blk", not "null". Make `pr_info()` follow
> the pattern of `pr_err()` log messages.
>
Instead of doing these fixes manually, it's more consistent and smarter
to use pr_fmt. There are many ex
On 9/11/19 10:02 PM, Ming Lei wrote:
> cecf5d87ff20 ("block: split .sysfs_lock into two locks") starts to
> release & actuire sysfs_lock again during switching elevator. So it
> isn't enough to prevent switching elevator from happening by simply
> clearing QUEUE_FLAG_REGISTERED with holding sysfs_l
On 9/12/19 2:35 AM, Stanley Chu wrote:
> Some devices may skip blk_pm_runtime_init() and have null pointer in
> its request_queue->dev. For example, SCSI devices of UFS Well-Known
> LUNs.
>
> Currently the null pointer is checked by the user of
> blk_set_runtime_active(), i.e., scsi_dev_type_resum
On Thu, Sep 12, 2019 at 04:49:15PM +0800, Yufen Yu wrote:
>
>
> On 2019/9/12 12:16, Ming Lei wrote:
> > On Thu, Sep 12, 2019 at 11:29:18AM +0800, Yufen Yu wrote:
> > >
> > > On 2019/9/12 10:46, Ming Lei wrote:
> > > > On Sat, Sep 07, 2019 at 06:24:50PM +0800, Yufen Yu wrote:
> > > > > There is a
On 9/12/19 5:29 AM, Yufen Yu wrote:
On 2019/9/12 10:46, Ming Lei wrote:
On Sat, Sep 07, 2019 at 06:24:50PM +0800, Yufen Yu wrote:
There is a race condition between timeout check and completion for
flush request as follow:
timeout_work issue flush issue flush
blk_i
On 2019/9/12 12:16, Ming Lei wrote:
On Thu, Sep 12, 2019 at 11:29:18AM +0800, Yufen Yu wrote:
On 2019/9/12 10:46, Ming Lei wrote:
On Sat, Sep 07, 2019 at 06:24:50PM +0800, Yufen Yu wrote:
There is a race condition between timeout check and completion for
flush request as follow:
timeout_w
Some devices may skip blk_pm_runtime_init() and have null pointer
in its request_queue->dev. For example, SCSI devices of UFS Well-Known
LUNs.
Currently the null pointer is checked by the user of
blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to
check it by blk_set_runtime_ac
Currently blk_set_runtime_active() is checking if q->dev is null by
itself, thus remove the same checking in its user: scsi_dev_type_resume().
Signed-off-by: Stanley Chu
---
drivers/scsi/scsi_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/driv
Some devices may skip blk_pm_runtime_init() and have null pointer in its
request_queue->dev. For example, SCSI devices of UFS Well-Known LUNs.
Currently the null pointer is checked by the user of blk_set_runtime_active(),
i.e., scsi_dev_type_resume(). It is better to check it by
blk_set_runtime
Hi Jens,
> > void blk_set_runtime_active(struct request_queue *q)
> > {
> > + if (!q->dev)
> > + return;
> > +
> > spin_lock_irq(&q->queue_lock);
> > q->rpm_status = RPM_ACTIVE;
> > pm_runtime_mark_last_busy(q->dev);
>
> I'd prefer just doing:
>
> if (q->dev) {
This is in my todo queue, which is big..
On Thu, Sep 12, 2019 at 08:57:29AM +0800, Ming Lei wrote:
> Could you explain a bit why we can't do that?
>
> The segment size limit is basically removed since the following commit
> 200a9aff7b02 ("block: remove the segment size check in bio_will_gap").
>
> Before that commit, the max segment siz
25 matches
Mail list logo
