Re: [PATCH] Memory management livelock

[Mikulas Patocka]

> > > yup, that's pretty much unfixable, really, unless new locks are added
> > > which block threads which are writing to unrelated sections of the
> > > file, and that could hurt some workloads quite a lot, I expect.
> > 
> > It is fixable with the patch I sent --- it doesn't take any locks unless 
> > the starvation happens. Then, you don't have to use .nr_to_write for 
> > fsync anymore.
> 
> I agree that the patch is low-impact and relatively straightforward. 
> The main problem is making the address_space larger - there can (and
> often are) millions and millions of these things in memory.  Making it
> larger is a big deal.  We should work hard to seek an alternative and
> afacit that isn't happening here.
> 
> We already have existing code and design which attempts to avoid
> livelock without adding stuff to the address_space.  Can it be modified
> so as to patch up this quite obscure and rarely-occuring problem?

I reworked my patch to use a bit in address_space->flags and hashes wait 
queues, so it doesn't take any extra memory. I'm sending it in three 
parts.
1 - make generic function wait_action_schedule
2 - fix the livelock, the logic is exactly the same as in my previous 
patch, wait_on_bit_lock is used instead of mutexes
3 - remove that nr_pages * 2 limit, because it causes misbehavior and 
possible data loss.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/