Messages in this thread | | | Subject | Re: per bdi dirty balancing (was Re: kupdate weirdness) | From | Peter Zijlstra <> | Date | Fri, 03 Aug 2007 09:15:27 +0200 |
| |
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 :-(
- 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/
| |