3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Manuel Reimer]

Hello,

maybe someone can help me to find the reason for this problem:

If I run my iMX233 development board with an 3.15.3 kernel, then the 
performance is much better as with an 3.15.4 kernel.

I have the first significant "hanging" here:

[    7.910000] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   10.810000] random: nonblocking pool is initialized
[   24.310000] systemd[1]: systemd 214 running in system mode. (+PAM 
-AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP 
-APPARMOR)

After booting up it takes several seconds between entering the username 
and the password while with version 3.15.3 the password prompt appears 
almost immediately after entering the username.

Please tell me if some additional information is needed.

Thank you very much in advance.

Greetings,

Manuel

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Guenter Roeck]

On Mon, Jul 07, 2014 at 08:21:38PM +0200, Manuel Reimer wrote:
> Hello,
> 
> maybe someone can help me to find the reason for this problem:
> 
> If I run my iMX233 development board with an 3.15.3 kernel, then the
> performance is much better as with an 3.15.4 kernel.
> 
> I have the first significant "hanging" here:
> 
> [    7.910000] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [   10.810000] random: nonblocking pool is initialized
> [   24.310000] systemd[1]: systemd 214 running in system mode. (+PAM
> -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
> +SECCOMP -APPARMOR)
> 
> After booting up it takes several seconds between entering the
> username and the password while with version 3.15.3 the password
> prompt appears almost immediately after entering the username.
> 

Are you sure this did not just happen when you booted the new kernel
for the first time ? I have seen similar behavior with some distributions.

If it happens all the time, ie at subsequent boots as wel, you'll probably
have to bisect the problem. I have not seen an obvious culprit.

Guenter

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Manuel Reimer]

On 07/07/2014 09:14 PM, Guenter Roeck wrote:
> Are you sure this did not just happen when you booted the new kernel
> for the first time ? I have seen similar behavior with some distributions.

I did some more tries and found out that I had disabled some of my 
patches until I reached 3.15.4 (latest version) where I decided to do 
needed modifications to get my patches back in.

I tracked the problem down to the following patch:


diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts 
b/arch/arm/boot/dts/imx23-olinuxino.dts
index d107c4a..993da2e 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -64,7 +64,14 @@
  				compatible = "fsl,imx23-spi";
  				pinctrl-names = "default";
  				pinctrl-0 = <&spi2_pins_a>;
+				clock-frequency = <1000000>;
  				status = "okay";
+
+				spidev0: spidev@0 {
+					compatible = "spidev";
+					spi-max-frequency = <1000000>;
+					reg = <0>;
+				};
  			};
  		};


I need this to add spidev support. But I don't understand why this 
change kills performance? Maybe the "high" value in "clock-frequency"? 
Can someone give me some information on how to fix this?

Thank you very much in advance.

Greetings,

Manuel

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Guenter Roeck]

On Mon, Jul 07, 2014 at 09:29:21PM +0200, Manuel Reimer wrote:
> On 07/07/2014 09:14 PM, Guenter Roeck wrote:
> >Are you sure this did not just happen when you booted the new kernel
> >for the first time ? I have seen similar behavior with some distributions.
> 
> I did some more tries and found out that I had disabled some of my
> patches until I reached 3.15.4 (latest version) where I decided to
> do needed modifications to get my patches back in.
> 
> I tracked the problem down to the following patch:
> 
> 
> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
> b/arch/arm/boot/dts/imx23-olinuxino.dts
> index d107c4a..993da2e 100644
> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
> @@ -64,7 +64,14 @@
>  				compatible = "fsl,imx23-spi";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&spi2_pins_a>;
> +				clock-frequency = <1000000>;

If I understand the code correctly, that means you reduce the access speed
for SPI flashes from 160 MHz down to 1 MHz.

If so, and if your system loads anything from a SPI flash, I would not be too
surprised that your system is now a bit on the slow side.

Guenter

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Manuel Reimer]

On 07/07/2014 09:42 PM, Guenter Roeck wrote:
>> I tracked the problem down to the following patch:
>>
>>
>> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
>> b/arch/arm/boot/dts/imx23-olinuxino.dts
>> index d107c4a..993da2e 100644
>> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
>> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
>> @@ -64,7 +64,14 @@
>>   				compatible = "fsl,imx23-spi";
>>   				pinctrl-names = "default";
>>   				pinctrl-0 = <&spi2_pins_a>;
>> +				clock-frequency = <1000000>;
>
> If I understand the code correctly, that means you reduce the access speed
> for SPI flashes from 160 MHz down to 1 MHz.
>
> If so, and if your system loads anything from a SPI flash, I would not be too
> surprised that your system is now a bit on the slow side.

The iMX233 has two separate SPI connections. The first one is used to 
connect to the SD card where the system boots from and the second one is 
the one I plan to use. The idea was to only set clock frequency for the 
SPI bus, I want to use to connect to external devices. The "SD SPI" has 
to run with "full speed". So where is the mistake...

Thanks in advance.

Greetings,

Manuel

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Geert Uytterhoeven]

On Mon, Jul 7, 2014 at 9:55 PM, Manuel Reimer
<Manuel.Spam@nurfuerspam.de> wrote:
> On 07/07/2014 09:42 PM, Guenter Roeck wrote:
>>>
>>> I tracked the problem down to the following patch:
>>>
>>>
>>> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
>>> b/arch/arm/boot/dts/imx23-olinuxino.dts
>>> index d107c4a..993da2e 100644
>>> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
>>> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
>>> @@ -64,7 +64,14 @@
>>>                                 compatible = "fsl,imx23-spi";
>>>                                 pinctrl-names = "default";
>>>                                 pinctrl-0 = <&spi2_pins_a>;
>>> +                               clock-frequency = <1000000>;
>>
>>
>> If I understand the code correctly, that means you reduce the access speed
>> for SPI flashes from 160 MHz down to 1 MHz.
>>
>> If so, and if your system loads anything from a SPI flash, I would not be
>> too
>> surprised that your system is now a bit on the slow side.
>
>
> The iMX233 has two separate SPI connections. The first one is used to
> connect to the SD card where the system boots from and the second one is the
> one I plan to use. The idea was to only set clock frequency for the SPI bus,
> I want to use to connect to external devices. The "SD SPI" has to run with
> "full speed". So where is the mistake...

drivers/spi/spi-mxs.c:mxs_spi_probe()

        ret = of_property_read_u32(np, "clock-frequency",
                                   &clk_freq);
        if (ret)
                clk_freq = clk_freq_default;

        ...

        ret = clk_prepare_enable(ssp->clk);

Any chance the clocks are shared, so this changes the rate for the
shared clock, affecting both SPI connections?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Manuel Reimer]

Hello,

maybe someone can help me to find the reason for this problem:

If I run my iMX233 development board with an 3.15.3 kernel, then the 
performance is much better as with an 3.15.4 kernel.

I have the first significant "hanging" here:

[    7.910000] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   10.810000] random: nonblocking pool is initialized
[   24.310000] systemd[1]: systemd 214 running in system mode. (+PAM 
-AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP 
-APPARMOR)

After booting up it takes several seconds between entering the username 
and the password while with version 3.15.3 the password prompt appears 
almost immediately after entering the username.

Please tell me if some additional information is needed.

Thank you very much in advance.

Greetings,

Manuel

Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU

[Marcelo Ricardo Leitner]

Em 07-07-2014 15:13, Manuel Reimer escreveu:
> Hello,

Hi,

> maybe someone can help me to find the reason for this problem:
>
> If I run my iMX233 development board with an 3.15.3 kernel, then the
> performance is much better as with an 3.15.4 kernel.
>
> I have the first significant "hanging" here:
>
> [    7.910000] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [   10.810000] random: nonblocking pool is initialized
> [   24.310000] systemd[1]: systemd 214 running in system mode. (+PAM
> -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP
> -APPARMOR)
>
> After booting up it takes several seconds between entering the username
> and the password while with version 3.15.3 the password prompt appears
> almost immediately after entering the username.
>
> Please tell me if some additional information is needed.

Did you try some git bisecting between these two versions, right? It's 
only 67 commits to go and it will probably give you the culprit right away.

Marcelo

> Thank you very much in advance.
>
> Greetings,
>
> Manuel
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html