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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox