#2604 closed bug (fixed)
Heavy I/O requests makes the system unusable
Reported by: | emitrax | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta2 |
Component: | System/Kernel | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Couldn't find a better summary, sorry.
I was running 4 instances of bonnie++, plus a wget -r on a website, but that was on a different bfs partition.
The system became unusable quite soon. It looks like an infinite loop and not a deadlock, as there always was a thread ready (low resource manager and scsi scheduler).
To summarize: one instance of bonnie++ was waiting on a condition variable in steal_pages while holding the bfs journal lock. All the other three instances of bonnie++ were waiting for the journal lock. The page writer thread was also waiting on a condition variable on vfs_write_pages -> Request::Wait() .
Unfortunately I forgot to check the scsi scheduler thread backtrace.
I hope it helps.
I'm attaching the serial log.
Attachments (1)
Change History (10)
by , 16 years ago
Attachment: | haiku-serial-port.txt added |
---|
comment:1 by , 16 years ago
comment:3 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 6 years ago
Nope, the GCC2 buildmaster builder is presently hung on exactly this state: some thread is holding the BFS journal lock and waiting, and all other threads wanting to do disk I/O are blocked waiting for it.
The page writer was also blocked on a cvar in ::Go.
comment:5 by , 6 years ago
Are you sure this was not virtio_block related? If so it would have hung waiting for the condition variable of the virtio request.
comment:6 by , 6 years ago
I didn't manage to locate the thread that was actually blocked and didn't locate this ticket until after I rebooted, so it's possible.
comment:7 by , 6 years ago
It is unfortunately somewhat common, so I would intuitively blame it on that and not on the issue described in this ticket. Finding the thread is usually easy: it's the last thread the build process forked off.
The setup described in this ticket seems easy enough to reproduce, so that should be tried and the ticket then closed or investigated.
comment:8 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Indeed, I can't reproduce this ticket anymore; the system gets somewhat sluggish but it never locks up altogether.
comment:9 by , 5 years ago
Milestone: | R1 → R1/beta2 |
---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Also note #2812.