(cc restored)
> > > There were heaps of problems in there and it is surprising how few people
> > > were hitting them. Ordered-mode journalling filesystems will fix it all up
> > > behind the scenes, of course.
> > >
> > > I just have a bad feeling about that code - list_heads are the wrong data
> > > structure and it all needs to be ripped and redone using some indexable
> > > data structure. There has been desultory discussion, but nothing's
> > > happening and nothing will happen in the medium term, so we need to keep
> > > on whapping bandainds on it.
> >
> > The reason why I'm looking at that code is because of those
> > balance_dirty_pages() deadlocks. I'm not perfectly happy with the
> > per-pdi-per-cpu counters Peter's patch is introducing.
>
> What is your biggest concern regarding them?
Complexity. I've started to review the patches, and they are just too
damn complex.
For example introducing the backing_dev_info initializer and
destructor adds potential bugs if we miss to add them somewhere.
Now maybe this is unavoidable. I'm just trying to look for a solution
involving less uncertanties and complexities.
My plan is to extract the minimal set of features from your patchset,
that solves the dirty balancing deadlocks and submit them as quickly
as possible.
After that we can look at trying to solve the more ambitious problem
of the slow vs. fast devices in a way that not only you can understand ;)
How's that?
Miklos
On Fri, 2007-08-03 at 08:43 +0200, Miklos Szeredi wrote:
> (cc restored)
>
> > > > There were heaps of problems in there and it is surprising how few people
> > > > were hitting them. Ordered-mode journalling filesystems will fix it all up
> > > > behind the scenes, of course.
> > > >
> > > > I just have a bad feeling about that code - list_heads are the wrong data
> > > > structure and it all needs to be ripped and redone using some indexable
> > > > data structure. There has been desultory discussion, but nothing's
> > > > happening and nothing will happen in the medium term, so we need to keep
> > > > on whapping bandainds on it.
> > >
> > > The reason why I'm looking at that code is because of those
> > > balance_dirty_pages() deadlocks. I'm not perfectly happy with the
> > > per-pdi-per-cpu counters Peter's patch is introducing.
> >
> > What is your biggest concern regarding them?
>
> Complexity. I've started to review the patches, and they are just too
> damn complex.
>
> For example introducing the backing_dev_info initializer and
> destructor adds potential bugs if we miss to add them somewhere.
yeah, that was/is a pain.
> Now maybe this is unavoidable. I'm just trying to look for a solution
> involving less uncertanties and complexities.
>
> My plan is to extract the minimal set of features from your patchset,
> that solves the dirty balancing deadlocks and submit them as quickly
> as possible.
I had hoped to post a new version yesterday, but lets hope for today.
> After that we can look at trying to solve the more ambitious problem
> of the slow vs. fast devices in a way that not only you can understand ;)
Drad, and here I thought all that documentation in the proportions lib
would have solved that :-(
> > My plan is to extract the minimal set of features from your patchset,
> > that solves the dirty balancing deadlocks and submit them as quickly
> > as possible.
>
> I had hoped to post a new version yesterday, but lets hope for today.
Would be cool.
> > After that we can look at trying to solve the more ambitious problem
> > of the slow vs. fast devices in a way that not only you can understand ;)
>
> Drad, and here I thought all that documentation in the proportions lib
> would have solved that :-(
Well, I didn't get that far, and only had a glimpse of the proportions
lib. But my hunch is that there's still lots of room for simplification.
Miklos