Re: [PATCH] again: Re: Athlon kernel crash (i686 works)

Re: [PATCH] again: Re: Athlon kernel crash (i686 works)

[Bryan Mayland]

I'm happy with this patch too, as it stops my machine from crashing when switching to user-space.
I've run several LMbench tests against both 686-optimized and Athlon-optimized kernels.  The
results waver across multiple tests, one kernel winning some tests one time and losing the next,
but the values are all close.  I can post the results of any benchmarks 686 vs Athlon anyone wants
me to run if we can get this patch in soon!

Here's the dump of my LMbench runs, if anyone wants to oggle the numbers:
                 L M B E N C H  2 . 0   S U M M A R Y
                 ------------------------------------


Basic system parameters
----------------------------------------------------
Host                 OS Description              Mhz

--------- ------------- ----------------------- ----
Athlon-1  Linux 2.4.10-       i686-pc-linux-gnu 1333
Athlon-2  Linux 2.4.10-       i686-pc-linux-gnu 1333
i686-1    Linux 2.4.10-       i686-pc-linux-gnu 1333
i686-2    Linux 2.4.10-       i686-pc-linux-gnu 1333

Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host                 OS  Mhz null null      open selct sig  sig  fork exec sh
                             call  I/O stat clos TCP   inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
Athlon-1  Linux 2.4.10- 1333 0.21 0.29 4.93 5.74  17.1 0.60 1.90 142. 770. 8593
Athlon-2  Linux 2.4.10- 1333 0.21 0.29 5.24 5.98  28.8 0.60 1.90 152. 823. 8771
i686-1    Linux 2.4.10- 1333 0.21 0.29 4.61 5.47  29.5 0.60 1.91 141. 776. 8670
i686-2    Linux 2.4.10- 1333 0.20 0.29 5.02 5.86  32.7 0.60 1.88 156. 870. 8871

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                        ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
Athlon-1  Linux 2.4.10- 1.030 1.2900   11.6 3.5800  125.5    20.2   126.7
Athlon-2  Linux 2.4.10- 0.820 1.3800   11.7 3.6200  125.8    27.4   126.2
i686-1    Linux 2.4.10- 0.820 1.3100   11.6 3.8400  125.8    24.6   125.9
i686-2    Linux 2.4.10- 0.590 1.2700   11.7 3.9100  125.5    20.7   126.1

*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
Athlon-1  Linux 2.4.10- 1.030 3.227 5.41 9.664  21.8  12.1  32.7 49.5
Athlon-2  Linux 2.4.10- 0.820 4.015 6.78  10.4  23.0  14.0  33.9 50.8
i686-1    Linux 2.4.10- 0.820 3.510 6.01 9.569  21.5  12.2  33.4 599K
i686-2    Linux 2.4.10- 0.590 4.153 6.75  10.1  23.0  13.2  34.1 18.M

File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host                 OS   0K File      10K File      Mmap    Prot    Page
                        Create Delete Create Delete  Latency Fault   Fault
--------- ------------- ------ ------ ------ ------  ------- -----   -----
Athlon-1  Linux 2.4.10-   29.1   41.5  190.1   66.0    523.0 0.448 2.00000
Athlon-2  Linux 2.4.10-   30.9   43.9  199.3   64.2    537.0 0.429 2.00000
i686-1    Linux 2.4.10-   29.0   41.9  209.4   65.2    532.0 0.634 2.00000
i686-2    Linux 2.4.10-   31.0   44.1  187.1   64.5    610.0 0.436 2.00000

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
Athlon-1  Linux 2.4.10- 847. 685. 311.  332.4  501.3  176.2  206.2 471. 342.5
Athlon-2  Linux 2.4.10- 882. 586. 187.  331.6  510.2  177.6  207.1 484. 343.5
i686-1    Linux 2.4.10- 863. 586. 299.  320.0  510.2  176.3  206.6 472. 342.6
i686-2    Linux 2.4.10- 874. 318. 199.  319.6  520.2  177.7  206.8 486. 343.5

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
Athlon-1  Linux 2.4.10-  1333 2.259   15.1  155.3
Athlon-2  Linux 2.4.10-  1333 2.259   15.1  155.4
i686-1    Linux 2.4.10-  1333 2.259   15.1  155.3
i686-2    Linux 2.4.10-  1333 2.259   15.1  155.3

No locking is needed ... why?

[Kirill Ratkin]

Hi.

Could somebody explain me this comment?:
/*
 * Incoming packets are placed on per-cpu queues so
that
 * no locking is needed.
 */

struct softnet_data
{
        int                     throttle;
        int                     cng_level;
        int                     avg_blog;
        struct sk_buff_head     input_pkt_queue;
        struct net_device       *output_queue;
        struct sk_buff          *completion_queue;
} __attribute__((__aligned__(SMP_CACHE_BYTES)));

I didn't understand why packets are placed so and why
locking isn't needed?


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: No locking is needed ... why?

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

Kirill Ratkin wrote:

>Hi.
>
>Could somebody explain me this comment?:
>/*
> * Incoming packets are placed on per-cpu queues so
>that
> * no locking is needed.
> */
>
>struct softnet_data
>{
>        int                     throttle;
>        int                     cng_level;
>        int                     avg_blog;
>        struct sk_buff_head     input_pkt_queue;
>        struct net_device       *output_queue;
>        struct sk_buff          *completion_queue;
>} __attribute__((__aligned__(SMP_CACHE_BYTES)));
>
>I didn't understand why packets are placed so and why
>locking isn't needed?
>

As I understand this, the only reason u lock is 

1) In an SMP or multiprocessor system, you suspect somebody else is running
   simultaneously with you, this can lead to two or more processors executing
   the same code simultaneously, this may lead to races.(which u do not want).
2) In a Multiprocessor or uniprocesor, data is shared among user processes in the kernel
   or
   between a user process in the kernel and an interrupt context
  (like an irq handler or a bottom half or a tasklet).

So if u have a situation where (2) does not hold and u have a multiprocessor system,
per CPU data need not be locked, since it is not visible/used by other processors.

Did I get it right?
Balbir

>
>__________________________________________________
>Do You Yahoo!?
>NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
>http://geocities.yahoo.com/ps/info1
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>




[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

Re: No locking is needed ... why?

[Rik van Riel]

On Tue, 9 Oct 2001, Kirill Ratkin wrote:

> Could somebody explain me this comment?:
> /*
>  * Incoming packets are placed on per-cpu queues so that
>  * no locking is needed.
>  */

> I didn't understand why packets are placed so and why
> locking isn't needed?

Each CPU has its own data structure here. This means no
other CPU will touch this queue (they have their own)
so there is nobody we could ever race against.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

http://www.surriel.com/		http://distro.conectiva.com/

Re: No locking is needed ... why?

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

>
>
>
>Each CPU has its own data structure here. This means no
>other CPU will touch this queue (they have their own)
>so there is nobody we could ever race against.
>
We would still require locking or interrupt disabling if this data is used
from an interrupt context (due to re-enterency issues), wouldn't we Rik?

Regards,
Balbir

>
>
>regards,
>
>Rik
>




[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

Re: No locking is needed ... why?

[Rik van Riel]

On Tue, 9 Oct 2001, BALBIR SINGH wrote:

> >Each CPU has its own data structure here. This means no
> >other CPU will touch this queue (they have their own)
> >so there is nobody we could ever race against.
>
> We would still require locking or interrupt disabling if this data is used
> from an interrupt context (due to re-enterency issues), wouldn't we Rik?

I think this code is only run from interrupt context anyway.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

http://www.surriel.com/		http://distro.conectiva.com/

Re: [PATCH] again: Re: Athlon kernel crash (i686 works)

[Bill Davidsen]

On Tue, 9 Oct 2001, Bryan Mayland wrote:

> I'm happy with this patch too, as it stops my machine from crashing when switching to user-space.
> I've run several LMbench tests against both 686-optimized and Athlon-optimized kernels.  The
> results waver across multiple tests, one kernel winning some tests one time and losing the next,
> but the values are all close.  I can post the results of any benchmarks 686 vs Athlon anyone wants
> me to run if we can get this patch in soon!

That's what I see... the patch doesn't make things faster, it prevents the
system from failing due to user space code. If it was just a speed thing I
wouldn't feel strongly about getting it in production.

The other thing is that I don't buy "some people don't need it" when some
people can't run without it and no one yet has stated that it impaired the
function of their system.

Given that some systems are vulnerable to user code induced failuers
without the patch, and there are no reports that the patch causes problems
on any system, and it's optional in config anyway, why the resistance. The
"we know what you need" attitude belongs in that other o/s, not
Linux. Make it experimental, there are lots of other "use at your own
risk" options in config!

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe