Messages in this thread | | | Date | Wed, 24 Sep 2008 14:50:23 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: [PATCH] Memory management livelock |
| |
> > > 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
| |