linux-kernel - Re: [RFC] Block IO Controller V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Nov 2009 19:32:28 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"Alan D. Brunelle" <Alan.Brunelle@...com>,
	linux-kernel@...r.kernel.org, jens.axboe@...cle.com
Subject: Re: [RFC] Block IO Controller V2 - some results

On Fri, Nov 20, 2009 at 4:04 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Fri, Nov 20, 2009 at 03:28:27PM +0100, Corrado Zoccolo wrote:
>> Hi Vivek,
>> On Fri, Nov 20, 2009 at 3:18 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
>> > Hi Corrado,
>> >
>> > I liked the idea of putting all the sync-noidle queues together in root
>> > group to achieve better throughput and implemeted a small patch.
>> >
>> > It works fine for random readers. But when I do multiple direct random writers
>> > in one group vs a random reader in other group, I am getting strange
>> > behavior. Random reader moves to root group as sync-noidle workload. But
>> > random writers are largely sync queues in remain in other group. But many
>> > a times also jump into root group and preempt random reader.
>>
>> can you try the attached patches?
>> They fix the problems you identified about no-idle preemption, and
>> deep seeky queues.
>> With those, you should not see this jumping any more.
>> I'll send them to Jens as soon has he comes back from vacation.
>>
>> Corrado
>>
>> > Anyway, with 4 random writers and 1 random reader running for 30 seconds
>> > in root group I get following.
>> >
>> > rw: 59,963KB/s
>> > rr: 66KB/s
>> >
>> > But if these are put in seprate groups test1 and test2 then
>> >
>> > rw: 30,587KB/s
>> > rr: 23KB/s
>> >
>
> I quickly tried your new patches to try to keep idling enabled on deep
> seeky sync queues so that it does not jump around too much and consume
> share both in sync workload and sync-noidle workload.
>
> Here are new results.
>
> Without cgroup.
>
> rw: 58,571KB/s
> rr: 83KB/s
>
> With cgroup:
>
> rw: 32,525KB/s
> rr: 25KB/s
>
> So without cgroup it looks like that random reader gained a bit and that's
> a good thing.

Great.
> With cgroup, problem still persists. I am wondering why both are loosing.
> Looks like I am idling somewhere otherwise at least one person should have
> gained.
With just 2 groups (one is the root), you can't be idling 50% of the
time. How is the disk utilization during the test?

Note that you can lose even if you're not idling enough.
How does this workload fare with noop or deadline?

Thanks
Corrado

>
> Thanks
> Vivek
>



-- 
__________________________________________________________________________

dott. Corrado Zoccolo                          mailto:czoccolo@...il.com
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
The self-confidence of a warrior is not the self-confidence of the average
man. The average man seeks certainty in the eyes of the onlooker and calls
that self-confidence. The warrior seeks impeccability in his own eyes and
calls that humbleness.
                               Tales of Power - C. Castaneda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/