Messages in this thread | | | Date | Fri, 20 Jan 2023 07:36:41 -0800 | From | Davidlohr Bueso <> | Subject | Re: [PATCH v2] locking/rwbase: Prevent indefinite writer starvation |
| |
On Fri, 20 Jan 2023, Mel Gorman wrote:
>locking/rwbase: Prevent indefinite writer starvation > >rw_semaphore and rwlock are explicitly unfair to writers in the presense >of readers by design with a PREEMPT_RT configuration. Commit 943f0edb754f >("locking/rt: Add base code for RT rw_semaphore and rwlock") notes; > > The implementation is writer unfair, as it is not feasible to do > priority inheritance on multiple readers, but experience has shown > that real-time workloads are not the typical workloads which are > sensitive to writer starvation. > >While atypical, it's also trivial to block writers with PREEMPT_RT >indefinitely without ever making forward progress. Since LTP-20220121, >the dio_truncate test case went from having 1 reader to having 16 readers >and the number of readers is sufficient to prevent the down_write ever >succeeding while readers exist. Eventually the test is killed after 30 >minutes as a failure. > >dio_truncate is not a realtime application but indefinite writer starvation >is undesirable. The test case has one writer appending and truncating files >A and B while multiple readers read file A. The readers and writer are >contending for one file's inode lock which never succeeds as the readers >keep reading until the writer is done which never happens. > >This patch records a timestamp when the first writer is blocked. DL / >RT tasks can continue to take the lock for read as long as readers exist >indefinitely. Other readers can acquire the read lock unless a writer >has been blocked for a minimum of 4ms. This is sufficient to allow the >dio_truncate test case to complete within the 30 minutes timeout. > >Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
LGTM (albeit Sebastian's last comment).
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
| |