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!
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
