From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5CF6ECE587 for ; Tue, 1 Oct 2019 23:02:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 939C32086A for ; Tue, 1 Oct 2019 23:02:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728727AbfJAXCU (ORCPT ); Tue, 1 Oct 2019 19:02:20 -0400 Received: from smtp1.cs.stanford.edu ([171.64.64.25]:42040 "EHLO smtp1.cs.Stanford.EDU" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728555AbfJAXCU (ORCPT ); Tue, 1 Oct 2019 19:02:20 -0400 Received: from mail-lj1-f173.google.com ([209.85.208.173]:43091) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iFR9u-0004c9-QS for netdev@vger.kernel.org; Tue, 01 Oct 2019 16:02:19 -0700 Received: by mail-lj1-f173.google.com with SMTP id n14so15097991ljj.10 for ; Tue, 01 Oct 2019 16:02:18 -0700 (PDT) X-Gm-Message-State: APjAAAXnB8fV+4iq9pE9Xky0peQg5IwqCYZo7nxdl+0TcjeDrXT6PC2k e0un77MkryVv1+rfsTPdHGUjoFQ8m8TCio9/im4= X-Google-Smtp-Source: APXvYqyklF+Ax9QgrnDKxLs0gBsdi3eqsZqfB08m32FxxgtFb9pF3qwP0eo817in14Q8soB+0xQcjuz1cX3eixv5BOw= X-Received: by 2002:a2e:8941:: with SMTP id b1mr221383ljk.40.1569970937794; Tue, 01 Oct 2019 16:02:17 -0700 (PDT) MIME-Version: 1.0 References: <01ac3ff4-4c06-7a6c-13fc-29ca9ed3ad88@gmail.com> <47fef079-635d-483e-b530-943b2a55fc22@gmail.com> In-Reply-To: From: John Ousterhout Date: Tue, 1 Oct 2019 16:01:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: BUG: sk_backlog.len can overestimate To: Eric Dumazet Cc: netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Oct 1, 2019 at 1:53 PM Eric Dumazet wrote: > > On 10/1/19 1:45 PM, John Ousterhout wrote: > > > > > But this isn't really about socket resource limits (though that is > > conflated in the implementation); it's about limiting the time spent > > in a single call to __release_sock, no? > > The proxy used is memory usage, not time usage. I apologize for being pedantic, but the proxy isn't memory usage; it's actually "number of bytes added to the backlog since the last time it was emptied". At the time the limit is hit, actual memory usage is probably a lot less than the limit. This was the source of my confusion, since I assumed you really *wanted* memory usage to be the limit. > cond_resched() or a preemptible kernel makes anything based on time flaky, > you probably do not want to play with a time limit... > > >