On Tuesday 11 December 2007 12:01, Jens Axboe wrote:
> On Tue, Dec 11 2007, Daniel Phillips wrote:
> > The problem is solved. The main cornerstone of the solution is
> > bio throttling, simply because the resources in question are
> > consumed by bio transactions.
>
> ... because too much is pushe
On Tuesday 11 December 2007 05:15, Jens Axboe wrote:
> As to the patch in question "fixing" it in the block layer, it's a
> fairly simple work around and I'm not totally against it. If you get
> rid of the ->bi_throttle stuff and just do sanity checks on the
> count, then we could look at getting s
On Tue, Dec 11 2007, Daniel Phillips wrote:
> On Tuesday 11 December 2007 05:15, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > > Now about that block writeout deadlock... it doesn't just affect my
> > > code, it basically breaks Linux as a storage platform, among other
> > >
On Tuesday 11 December 2007 05:15, Jens Axboe wrote:
> On Mon, Dec 10 2007, Daniel Phillips wrote:
> > Now about that block writeout deadlock... it doesn't just affect my
> > code, it basically breaks Linux as a storage platform, among other
> > things.
>
> As written in other similar threads in th
On Mon, Dec 10 2007, Daniel Phillips wrote:
> Now about that block writeout deadlock... it doesn't just affect my
> code, it basically breaks Linux as a storage platform, among other
> things.
As written in other similar threads in the past in which you also
participated, I still of the opinion
On Monday 10 December 2007 05:53, Jens Axboe wrote:
> > Got a plan? Or does endless, pointless flaming feel more like
> > progress to you?
>
> Please, I'm not flaming you. I reviewed your code and pointed out
> errors, which was followed by lots of hand waving on your side
> instead of just sittin
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 05:30, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > "Let me close with perhaps the most relevant remarks: the attached
> > code has been in heavy testing and in production for months now.
> > Thus the
On Monday 10 December 2007 05:30, Jens Axboe wrote:
> On Mon, Dec 10 2007, Daniel Phillips wrote:
> "Let me close with perhaps the most relevant remarks: the attached
> code has been in heavy testing and in production for months now.
> Thus there is nothing theoretical when I say it works, and the
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 05:19, Jens Axboe wrote:
> > Precisely. So forgive me for thinking this patch hasn't seen very
> > varied testing, that's 2 errors (one simple, one bad - broken was NOT
> > a gross exageration, thanks) in very few lines.
>
>
On Monday 10 December 2007 05:19, Jens Axboe wrote:
> Precisely. So forgive me for thinking this patch hasn't seen very
> varied testing, that's 2 errors (one simple, one bad - broken was NOT
> a gross exageration, thanks) in very few lines.
See the [RFC]? If I had meant Request For Flaming, I wo
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 04:32, Jens Axboe wrote:
> > I honestly don't know how to make this any clearer than I already did
> > above.
>
> Sure you do, you could cut out the rhetoric and save lots of bandwidth
> thereby.
I spent 3 mail explaining i
On Monday 10 December 2007 04:32, Jens Axboe wrote:
> I honestly don't know how to make this any clearer than I already did
> above.
Sure you do, you could cut out the rhetoric and save lots of bandwidth
thereby.
Yes, the q = bdev_get_queue(bio->bi_bdev) needs to be repeated inside
the submissi
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 04:16, Jens Axboe wrote:
> > OK, let me get the neon out then. This has nothing to do with
> > throttling, I thought I made it clear that I get why you store the
> > origin queue in ->bi_queue. I'm concerned with the workings
On Monday 10 December 2007 04:16, Jens Axboe wrote:
> OK, let me get the neon out then. This has nothing to do with
> throttling, I thought I made it clear that I get why you store the
> origin queue in ->bi_queue. I'm concerned with the workings of
> redirecting a bio. Previously we looked up the
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 03:41, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > > + if (q && q->metric && !bio->bi_queue) {
> > >
> > > This prevents any reference to bi_bdev after the intial call to
> > > generic_make_requ
On Monday 10 December 2007 03:41, Jens Axboe wrote:
> On Mon, Dec 10 2007, Daniel Phillips wrote:
> > + if (q && q->metric && !bio->bi_queue) {
> >
> > This prevents any reference to bi_bdev after the intial call to
> > generic_make_request. Thanks to Evgeniy for pointing out the need
> > fo
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 02:47, Jens Axboe wrote:
> > Ehm, this patch is so broken it's not even funny - did you even
> > compile? You would have noticed the warning on request_queue_t,
> > surely. The big problem is the last hunk here though, how wou
On Monday 10 December 2007 02:47, Jens Axboe wrote:
> Ehm, this patch is so broken it's not even funny - did you even
> compile? You would have noticed the warning on request_queue_t,
> surely. The big problem is the last hunk here though, how would that
> work on stacked devices? Clue: ->bi_bdev i
18 matches
Mail list logo
