Re: linux-next: Tree for Aug 26 (git-bisect: [0856a30] Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 26, 2011 at 7:00 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
>
> Changes since 20110825:
>
> The slave-dma tree gained a conflict against Linus' tree.
>
> I have reverted the x86/spinlocks branch from the tip tree for today.
>
> The ptrace tree lost its build failure.
>
> The xen tree lost its conflict since I reveretd the version of the same
> patches in the tip tree..
>
> The tty tree still has its build failure but I applied a supplied test
> patch for it.
>
> The staging tree lost its build failures and gained a conflict against
> the net tree.
>
> The moduleh tree lost a conflict.
>
> The akpm tree lost its build failure.
>
> ----------------------------------------------------------------------------
>

Hi,

I saw diverse strange kernel-panics letting my notebook blink and
scream a high-frequency tone, really ugly.

My last good linux-next (l-n) kernel was next-20110818 and the next
l-n kernel in series which I built and was broken: next-20110826.
( BTW, 29/31 Aug are broken too. )

For the correctness I built 22/23/24/25 Aug which were all good.
As usual when I do once a year a git-bisect... its the last step of 12
steps in total (see git-bisect_visualize.txt and
git-bisect_view-stat.txt).

I was irritated by using next-20110825 and next-20110826 as git-bisect
good and bad, as the first offered commit-id pointed me to
3.1-rc1-665-gec5efe7, but I was sure the culprit is definitely
v3.1-rc3+ and furthermore I got no info how many revisions have to be
walked through. So, I cancelled this run.

Next thought was to do a git format-patch using above mentionned
commit-ids (of the tags): 819 single patches.
I took the commit-ids of 0001 (good) and 0818 (bad) - 0819 was
linux-specific mumbo-jumbo.

Jiri has reported a similiar breakage in [2] and returning CULPRIT
commit [1] helped him.
( This git-bisect steal a whole Friday. Anyway, it's good to see we
isolated the "bad" patch. )

As a personal conclusion, trust more git-bisect...
It does not hurt to NOT turn off brain my looking over the single
patches, there were lots of staging, arm, powerpc which could be
surely ignored, but in the end you are wiser - 12 steps are faster
than reverting xxx single commits on spec.

- Sedat -

[1] http://git.us.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0856a304091b33a8e8f9f9c98e776f425af2b625
[2] http://lkml.org/lkml/2011/9/1/332
[3] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
[4] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect

P.S.: Used 0001 (good) and 0818 (bad) for git-bisect

$ head -5 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch
0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch
==> 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch <==
>From eb39d34004888afcc0a44d9c36383cd69fa3b3b9 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
Date: Tue, 26 Jul 2011 16:59:00 -0700
Subject: [PATCH 001/819] target: Change TCM_NON_EXISTENT_LUN response to
 ASC=LOGICAL UNIT NOT SUPPORTED

==> 0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch <==
>From 9b198e560524e3fe341cd2ae478a1cdf2f57fc33 Mon Sep 17 00:00:00 2001
From: Clifton Barnes <cabarnes@xxxxxxxxxxxxxxxx>
Date: Thu, 25 Aug 2011 09:47:59 +1000
Subject: [PATCH 818/819] Fixes the deadlock when inserting and removing the
 ds2780.
git bisect start
# good: [eb39d34004888afcc0a44d9c36383cd69fa3b3b9] target: Change TCM_NON_EXISTENT_LUN response to ASC=LOGICAL UNIT NOT SUPPORTED
git bisect good eb39d34004888afcc0a44d9c36383cd69fa3b3b9
# bad: [9b198e560524e3fe341cd2ae478a1cdf2f57fc33] Fixes the deadlock when inserting and removing the ds2780.
git bisect bad 9b198e560524e3fe341cd2ae478a1cdf2f57fc33
# bad: [849e421eeada38a083768ab4a94a6d39fb0ac33e] Merge remote-tracking branch 'sound/for-next'
git bisect bad 849e421eeada38a083768ab4a94a6d39fb0ac33e
# bad: [c42ad7c77628946986ebe688966638371d09b734] Merge remote-tracking branch 'net/master'
git bisect bad c42ad7c77628946986ebe688966638371d09b734
# good: [fb7f42b72254bb7b2b5327efd8386d260cbfcd94] Merge remote-tracking branch 'ext4/dev'
git bisect good fb7f42b72254bb7b2b5327efd8386d260cbfcd94
# good: [fd3209922476593f3aa0dc57f0c0a61c50dd6c0f] Merge remote-tracking branch 'scsi/master'
git bisect good fd3209922476593f3aa0dc57f0c0a61c50dd6c0f
# good: [0dfe178239453547d4297a4583ee7847948a481b] net: vlan: goto another_round instead of calling __netif_receive_skb
git bisect good 0dfe178239453547d4297a4583ee7847948a481b
# good: [ad226ec22b92d7f0f834015149b1d1118e017f16] ath6kl: fix function name conflicts with ath9k
git bisect good ad226ec22b92d7f0f834015149b1d1118e017f16
# good: [131ea6675c761f655d43b808dd0fe83d15d5cdd3] net: add APIs for manipulating skb page fragments.
git bisect good 131ea6675c761f655d43b808dd0fe83d15d5cdd3
# good: [43f0f23b4ae4932f7746bede8a75d37dfed186d6] Merge remote-tracking branch 'slave-dma/next'
git bisect good 43f0f23b4ae4932f7746bede8a75d37dfed186d6
# good: [09c1c68f2239dcd99b76be2c44e84811fba273db] be2net: fix erx->rx_drops_no_frags wrap around
git bisect good 09c1c68f2239dcd99b76be2c44e84811fba273db
# good: [44331fe2aa0d7eed54e68484df58e9e00aee0f6e] IEEE802.15.4: 6LoWPAN basic support
git bisect good 44331fe2aa0d7eed54e68484df58e9e00aee0f6e
# good: [a262f0cdf1f2916ea918dc329492abb5323d9a6c] Proportional Rate Reduction for TCP.
git bisect good a262f0cdf1f2916ea918dc329492abb5323d9a6c
# good: [6af29ccc223b0feb6fc6112281c3fa3cdb1afddf] sctp: Bundle HEAERTBEAT into ASCONF_ACK
git bisect good 6af29ccc223b0feb6fc6112281c3fa3cdb1afddf
commit c42ad7c77628946986ebe688966638371d09b734
Merge: 43f0f23 0856a30
Author: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
Date:   Fri Aug 26 11:50:02 2011 +1000

    Merge remote-tracking branch 'net/master'
    
    Conflicts:
    	arch/powerpc/configs/40x/hcu4_defconfig
    	drivers/net/Kconfig
    	drivers/net/Makefile

commit 0856a304091b33a8e8f9f9c98e776f425af2b625
Author: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
Date:   Mon Aug 22 14:57:26 2011 +0000

    Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path
    
    Patch series 109f6e39..7361c36c back in 2.6.36 added functionality to
    allow credentials to work across pid namespaces for packets sent via
    UNIX sockets.  However, the atomic reference counts on pid and
    credentials caused plenty of cache bouncing when there are numerous
    threads of the same pid sharing a UNIX socket.  This patch mitigates the
    problem by eliminating extraneous reference counts on pid and
    credentials on both send and receive path of UNIX sockets. I found a 2x
    improvement in hackbench's threaded case.
    
    On the receive path in unix_dgram_recvmsg, currently there is an
    increment of reference count on pid and credentials in scm_set_cred.
    Then there are two decrement of the reference counts.  Once in scm_recv
    and once when skb_free_datagram call skb->destructor function
    unix_destruct_scm.  One pair of increment and decrement of ref count on
    pid and credentials can be eliminated from the receive path.  Until we
    destroy the skb, we already set a reference when we created the skb on
    the send side.
    
    On the send path, there are two increments of ref count on pid and
    credentials, once in scm_send and once in unix_scm_to_skb.  Then there
    is a decrement of the reference counts in scm_destroy's call to
    scm_destroy_cred at the end of unix_dgram_sendmsg functions.   One pair
    of increment and decrement of the reference counts can be removed so we
    only need to increment the ref counts once.
    
    By incorporating these changes, for hackbench running on a 4 socket
    NHM-EX machine with 40 cores, the execution of hackbench on
    50 groups of 20 threads sped up by factor of 2.
    
    Hackbench command used for testing:
    ./hackbench 50 thread 2000
    
    Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

 include/net/scm.h  |   22 +++++++++++++++++++---
 net/unix/af_unix.c |   45 +++++++++++++++++++++++++++++----------------
 2 files changed, 48 insertions(+), 19 deletions(-)
commit c42ad7c77628946986ebe688966638371d09b734
Merge: 43f0f23 0856a30
Author: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
Date:   Fri Aug 26 11:50:02 2011 +1000

    Merge remote-tracking branch 'net/master'
    
    Conflicts:
    	arch/powerpc/configs/40x/hcu4_defconfig
    	drivers/net/Kconfig
    	drivers/net/Makefile

commit 0856a304091b33a8e8f9f9c98e776f425af2b625
Author: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
Date:   Mon Aug 22 14:57:26 2011 +0000

    Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path
    
    Patch series 109f6e39..7361c36c back in 2.6.36 added functionality to
    allow credentials to work across pid namespaces for packets sent via
    UNIX sockets.  However, the atomic reference counts on pid and
    credentials caused plenty of cache bouncing when there are numerous
    threads of the same pid sharing a UNIX socket.  This patch mitigates the
    problem by eliminating extraneous reference counts on pid and
    credentials on both send and receive path of UNIX sockets. I found a 2x
    improvement in hackbench's threaded case.
    
    On the receive path in unix_dgram_recvmsg, currently there is an
    increment of reference count on pid and credentials in scm_set_cred.
    Then there are two decrement of the reference counts.  Once in scm_recv
    and once when skb_free_datagram call skb->destructor function
    unix_destruct_scm.  One pair of increment and decrement of ref count on
    pid and credentials can be eliminated from the receive path.  Until we
    destroy the skb, we already set a reference when we created the skb on
    the send side.
    
    On the send path, there are two increments of ref count on pid and
    credentials, once in scm_send and once in unix_scm_to_skb.  Then there
    is a decrement of the reference counts in scm_destroy's call to
    scm_destroy_cred at the end of unix_dgram_sendmsg functions.   One pair
    of increment and decrement of the reference counts can be removed so we
    only need to increment the ref counts once.
    
    By incorporating these changes, for hackbench running on a 4 socket
    NHM-EX machine with 40 cores, the execution of hackbench on
    50 groups of 20 threads sped up by factor of 2.
    
    Hackbench command used for testing:
    ./hackbench 50 thread 2000
    
    Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux