Messages in this thread | | | Date | Thu, 6 Jan 2005 06:59:05 +0100 | From | Andrea Arcangeli <> | Subject | Re: [PATCH][5/?] count writeback pages in nr_scanned |
| |
On Wed, Jan 05, 2005 at 09:37:04PM -0800, Andrew Morton wrote: > Andrea Arcangeli <andrea@suse.de> wrote: > > > > 2) we won't need unreliable anti-deadlock timeouts anymore > > The timeouts are for: > > a) A fallback for backing stores which don't wake up waiters in > blk_congestion_wait() (eg: NFS).
that anti-deadlock will be unnecessary too with the new logic.
> b) handling the race case where the request queue suddenly goes empty > before the sleeper gets onto the waitqueue.
as I mentioned with proper locking setting task in uninterruptible and then registering into the new per classzone waitqueue, the timeout will be unnecessary even for this.
> It can probably be removed with some work, and additional locking.
The additional locking will then remove the current locking in blk_congestion_wait so it's new locking but it will replace the current locking. But I agree registering in the waitqueue inside the blk_congestion_wait was simpler. It's just I've an hard time to like the timeout. Timeout is always wrong when it triggers: if it triggers it always triggers either too late (wasted resources) or too early (early oom kills). So unless it messes everything up, it'd be nice to the locking strict. anyway point 1 and 2 can be implemented separately, at first we can leave the timeout if the race is too hard to handle.
Ideally if we keep the total number of oustanding writebacks per-classzone (not sure if we account for it already somewhere, I guess if something we've the global number and not the per-classzone one), we could remove the timeout without having to expose the locking outside blk_congestion_wait. With the number of oustanding writebacks per-classzone we could truly fix the race and obsolete the timeout in a self contained manner. Though it will require a proper amount of memory barriers around the account increment/decrement/read. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |