Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Dave Watson <davejwatson@fb.com>
To:     "lsf-pc@lists.linux-foundation.org" 
        <lsf-pc@lists.linux-foundation.org>
CC:     "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Maged Michael <magedmichael@fb.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [LSF/MM TOPIC] Improve performance of fget/fput
Thread-Topic: [LSF/MM TOPIC] Improve performance of fget/fput
Thread-Index: AQHUxUzTqmvWMcBbakqADGu841l6Tg==
Date:   Fri, 15 Feb 2019 16:38:05 +0000
Message-ID: <20190215163852.6ls6bchssazma6bm@davejwatson-mba.local>
Accept-Language: en-US
Content-Language: en-US
user-agent: NeoMutt/20180716
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1:5b6b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 937aeb10-44f2-4279-d6b0-08d69363f492
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020);SRVR:MWHPR15MB1693;
x-ms-traffictypediagnostic: MWHPR15MB1693:
x-microsoft-exchange-diagnostics: 1;MWHPR15MB1693;20:004eTB3wBN9EasGDlcpi5/JlQcufGjjWApEx0bb1cniwMhQgyAb4zfD+yYF9OygsLR3pZoHlbablub7+K4bz2v0mtGJac9lnpAs771mn15M/6Gr1QEAubTVQwLaKAVz18tjHUrr6A00JJhYYlVGj/hzRJx4b378YOCou7ozciHM=
x-microsoft-antispam-prvs: <MWHPR15MB16937596A9754DB8DEE58DAFDD600@MWHPR15MB1693.namprd15.prod.outlook.com>
x-forefront-prvs: 09497C15EB
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(199004)(189003)(7736002)(386003)(8936002)(99286004)(102836004)(6506007)(52116002)(81166006)(33896004)(14454004)(2906002)(98436002)(2501003)(25786009)(561944003)(81156014)(53936002)(8676002)(105586002)(106356001)(2351001)(5640700003)(6916009)(6486002)(71200400001)(71190400001)(6436002)(4326008)(256004)(97736004)(6116002)(478600001)(305945005)(9686003)(6512007)(476003)(316002)(486006)(1076003)(68736007)(54906003)(86362001)(58126008)(46003)(186003);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR15MB1693;H:MWHPR15MB1134.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: f7Uo61VHvsEGrirHwGzqpDGuZB+6Ltw5ofoiBeSK8EP8pagxzMOT1OQa5YjO+hG+LyDOY+6ffxEm8fKAdOwysMpzmIxCl42Oew7ZkF/EB5yiyvaaY87VEVWzJWTQgXvSRBlnFx5QgQpan5UiMjjm14a8JPHoU83qNd7HHqsPOCC7pIMd5ErbfDKEcFoJ2Jf+ys+vJoHg62jdhB8Et+NJ9N0p66Hb12wYTLdqbE38wtdDqkAuz9x9bAcb1hH96yDJAb39yl4wGzC3IMGXDpZhHUFaeqrYCZaZ2HQ0vqk8KnkknPJxO1GsgHYOlrPiojRuRZPqe+VrQIbdPxBZ9gy24PvhTD8BbiPxx63TdwIJs4C5J5sHRmayVFHdXTLp6fqNo/0W1k6Mp0bpUMEdkUqwHuP28WyNBrF0yOjYK5D8e/A=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3D753BDD5C51904C81AE759469E1EF38@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 937aeb10-44f2-4279-d6b0-08d69363f492
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 16:38:02.3744
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1693
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-15_12:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

In some of our hottest network services, fget_light + fput overhead
can represent 1-2% of the processes' total CPU usage.  I'd like to
discuss ways to reduce this overhead.

One proposal we have been testing is removing the refcount increment
and decrement, and using some sort of safe memory reclamation
instead. The hottest callers include recvmsg, sendmsg, epoll_wait, etc
- mostly networking calls, often used on non-blocking sockets.  Often
we are only incrementing and decrementing the refcount for a very
short period of time, ideally we wouldn't adjust the refcount unless
we know we are going to block.

We could use RCU, but we would have to be particularly careful that
none of these calls ever block, or ensure that we increment the
refcount at the blocking locations.  As an alternative to RCU, hazard
pointers have similar overhead to SRCU, and could work equally well on
blocking or nonblocking syscalls without additional changes.

(There were also recent related discussions on SCM_RIGHTS refcount
cycle issues, which is the other half of a file* gc)

There might also be ways to rearrange the file* struct or fd table so
that we're not taking so many cache misses for sockfd_lookup_light,
since for sockets we don't use most of the file* struct at all.