All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Avi Kivity <avi@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: the >1Tb  block issue
Date: Tue, 18 May 2010 22:43:13 +0400	[thread overview]
Message-ID: <4BF2DFC1.4070307@msgid.tls.msk.ru> (raw)
In-Reply-To: <4BF2DEB1.2010109@msgid.tls.msk.ru>

18.05.2010 22:38, Michael Tokarev пишет:
> 18.05.2010 22:09, Avi Kivity wrote:
>> On 05/18/2010 09:03 PM, Michael Tokarev wrote:
>>> 18.05.2010 21:38, Avi Kivity wrote:
>>>
>>>>> [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping
>>>>> requests
>>>>>
>>>>> quick tests shows it works correctly so far.
>>>>> At least it went further than before, not
>>>>> stopping at the "usual" sector 3145727872.
>>>>>
>>>>> Hmm. Ide has no queue, hence no mergeing,
>>>>> that's why it does not occur with ide,
>>>>> right? :)
>>>>
> []
>>>> Yes. Why would Linux post overlapping requests? makes
>>>> 0xffffffff00000000
>>>> sense.
> []
>>> Note also that it's not as on the original bugreport -
>>> there, the sector# is apparently different:
>>> http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831
>>>
>>
>> I don't think it's related to a particular sector number.
>
> I added a debug printf into the place that is touched
> by the patch mentioned above, to print the case where
> the request were merged before that patch but not any
> more with it applied:
>
> if (reqs[i].sector == oldreq_last) {
> merge = 1;
> }
> else if (reqs[i].sector < oldreq_last)
> fprintf(stderr, "NOT mergeing:\n"
> " reqs[i].sector=%Ld oldreq_last=%Ld\n"
> " reqs[outidx].sector=%Ld reqs[outidx].nb_sectors=%d\n"
> , reqs[i].sector, oldreq_last,
> reqs[outidx].sector, reqs[outidx].nb_sectors);
>
> In a few runs it showed different info (and I modified the
> printf line 2 times too):
>
> NOT mergeing: reqs[i].sector=92306456 oldreq_last=3145728000
> NOT mergeing:
> reqs[i].sector=92322056 oldreq_last=3145728000
> reqs[outidx].sector=3145727872
> NOT mergeing:
> reqs[i].sector=0 oldreq_last=3145728000
> reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
> NOT mergeing:
> reqs[i].sector=0 oldreq_last=3145728000
> reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
> NOT mergeing:
> reqs[i].sector=92308152 oldreq_last=3145728000
> reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
> NOT mergeing:
> reqs[i].sector=0 oldreq_last=3145728000
> reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128

> So it's definitely timing-related somehow (esp. it changes
> when interrupting mkfs and immediately starting again), and
> shows different values, but for me it's - apparently - always
> reqs[outidx].sector=3145727872 together with some other sector.

And once I hit "Send" it showed another:

NOT mergeing:
  reqs[i].sector=760 oldreq_last=3141599488
  reqs[outidx].sector=3141597896 reqs[outidx].nb_sectors=1592

so it's not the case here ;)

> /mjt

  reply	other threads:[~2010-05-18 18:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 15:52 the >1Tb block issue Michael Tokarev
2010-05-18 15:59 ` Daniel P. Berrange
2010-05-18 16:51 ` Michael Tokarev
2010-05-18 16:58   ` Gleb Natapov
2010-05-18 17:29 ` Avi Kivity
2010-05-18 17:34   ` Michael Tokarev
2010-05-18 17:38     ` Avi Kivity
2010-05-18 18:03       ` Michael Tokarev
2010-05-18 18:09         ` Avi Kivity
2010-05-18 18:38           ` Michael Tokarev
2010-05-18 18:43             ` Michael Tokarev [this message]
2010-05-19  8:57       ` Christoph Hellwig
2010-05-19  9:03         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF2DFC1.4070307@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.