linux-kernel - Re: linux-next: Tree for December 27

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]

Message-ID: <4D19FDA5.6040601@example.com>
Date:	Tue, 28 Dec 2010 16:09:25 +0100
From:	Piotr Hosowicz <piotr@...owicz.com>
To:	piotr@...owicz.com
CC:	sedat.dilek@...il.com, Sedat Dilek <sedat.dilek@...glemail.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for December 27

On 28.12.2010 15:27, Piotr Hosowicz wrote:
> On 27.12.2010 17:16, Sedat Dilek wrote:
>> 2010/12/27 Piotr Hosowicz<piotr@...owicz.com>:
>>> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>>>
>>>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>>>
>>>>> 2010/12/27 Piotr Hosowicz<piotr@...owicz.com>:
>>>>>>
>>>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>>>
>>>>>>> 2010/12/27 Piotr Hosowicz<piotr@...owicz.com>:
>>>>>>>>
>>>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>>>> collection
>>>>>>>> in
>>>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>>>> because
>>>>>>>> I
>>>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>>>> is not
>>>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>>>> in tht
>>>>>>>> dir?) if somebody needs it.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Piotr Hosowicz
>>>>>>>>
>>>>>>>
>>>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>>>
>>>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>>>
>>>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>>>
>>>>>
>>>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>>>> default"
>>>>
>>>> I tried to Google for mblk_io_submit but I didn't find anything
>>>> helpful.
>>>> Could you tell me how should I add this option in fstab and what
>>>> will be
>>>> its effect?
>>>
>>> As far as I understand that option regards writing, not reading. The
>>> symptoms I described occured while reading only.
>>>
>>
>> That's the only performance issue I am aware of in ext4 in recent time.
>> Why don't you try it and present some numbers in transfer ratio
>> (write, read)?
>
> Ok, I'll try to measure it in shell. Now I am building newest non-next
> kernel and the trial script is:
>
> #!/bin/bash
>
> uname -a
> mount
> cd /data/music
> time ls -d *
> cd -
>
> This is basically what mocp does when it enters my music directory,
> apart from displaying the results in ncurses based UI. Then I'll reboot
> with next kernel and run it again. Will it do?

Sorry for the desinformation, now I see that there must be some othe 
things that mocp does because when I measured it I see that my initial 
observaions were false. The script is attached, plain is the newest 
ordinary kernel 2.6.37-rc7-git5, _1 file is the first run, _2 is the 
second run. Similarily the next_ files, after mounting / with the option 
in question. They show no big difference between the kernels.

Regards,

Piotr Hosowicz

-- 
Babcia rox! :
alek:   przyszli do mnie jehowi dzisiaj, otworzyła babcia
pate_q: i co?
alek:   po 30 minutach rozmowy chcieli przejść na chrześcijaństwo
NP: Peter Green Splinter Group - Heart Of Stone
NB: 2.6.37-rc7-git5

View attachment "next_1.txt" of type "text/plain" (3608 bytes)

View attachment "next_2.txt" of type "text/plain" (3608 bytes)

View attachment "plain_1.txt" of type "text/plain" (3584 bytes)

View attachment "plain_2.txt" of type "text/plain" (3584 bytes)

Download attachment "test.sh" of type "application/x-sh" (89 bytes)