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