Hello,
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 background
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 recently observed slowness, 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. I might be missing something here. Let me know if you have
questions. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
