lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-09-24 20:53    [W:0.083 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site