Can block driver kthread slow down blkid and other processes?

Can block driver kthread slow down blkid and other processes?

[Alvin Abitria]

Hello Gurus,



I'm currently creating a Linux driver for block devices.  This has been
going on for some time, and I just recently changed the driver design from
bio-mode to request-mode (I used to handle struct bio but now I'm operating
on struct request) and it made the functionality simpler, but the change
also presented some new issues of which I'm requesting advice.  I'm also
using a kthread for backgrond maintenance and periodic flushing of entries
in my driver-device circular buffers.



One of those issues that I'm having difficulty handling or fully
understanding is regarding the slowness and presence of sbin/blkid process
after entering commands that alter partition or filesystem type.  With my
current design, whenever I run fdisk or mkfs or just any command that
modify the partition/FS type, upon checking running processes via the ps
-ef terminal command, the blkid process runs afterwards and will take
around a minute or two before completing and updating drive info in Disk
Utility (which the user sees).  This is of course too long to wait, and I
have to wait before entering another command that modify the partition/FS
type, or else the drive info gets messed up, partition table is lost, etc.



I found out that when I came back to my previous bio-mode driver (which did
not have kthread) that this blkid task also runs after the same commands as
above, but finishes very quickly!  I just became aware of blkid because of
its slowness now, and not then because it easily completes.  And so I
decided to play with my driver code, removing stuffs to see which code
segment causes slow blkid, and eventually found that the presence of
kthread correlates to the slowness of blkid.



The body of my kthread BTW looks as follows:



        while (kthread_should_stop()) {

                set_current_state(TASK_INTERRUPTIBLE);

                spin_lock_irq(&lock);



                < driver code here... >



                spin_unlock_irq(&lock);

                schedule_timeout(msecs_to_jiffies(250));

        }





Here's what I did to my kthread:

- slowly remove code until nothing is left between the spin_lock/unlock
calls - blkid is still slow.

- remove kthread and replace it with timer that periodically expires,
resets itself, and upon every expiry calls a function, to which I moved the
contents of the kthread driver code - blkid is still slow

- change the schedule_timeout time value from 250ms to 1s - blkid became
even slower to complete > 3mins.  If I lessen it to 50ms, it's as slow as
during 250ms timeout.


I'm really confused - how does my driver kthread and blkid interact in such
a way it slows down blkid?  Or at least any new perspective on this. Let me
know if you have questions.  Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140914/d37fc130/attachment.html 

Can block driver kthread slow down blkid and other processes?

[Greg KH]

On Sun, Sep 14, 2014 at 09:53:03PM +0800, Alvin Abitria wrote:
> Hello Gurus,

Try posting your code to the linux-fsdevel at vger.kernel.org mailing list.
The developers there should be able to help you out with these
questions.

thanks,

greg k-h

Can block driver kthread slow down blkid and other processes?

[Alvin Abitria]

I see.  Thanks Greg!  Just posted to the mailing list you mentioned.

On Sun, Sep 14, 2014 at 11:35 PM, Greg KH <greg@kroah.com> wrote:

> On Sun, Sep 14, 2014 at 09:53:03PM +0800, Alvin Abitria wrote:
> > Hello Gurus,
>
> Try posting your code to the linux-fsdevel at vger.kernel.org mailing list.
> The developers there should be able to help you out with these
> questions.
>
> thanks,
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140915/b82beba8/attachment.html