From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net-next] tcp: forbid direct reclaim if MSG_DONTWAIT is set in send path Date: Tue, 9 Oct 2018 18:44:05 -0700 Message-ID: <1bda85f1-e369-b95e-6f50-a7f795634d03@gmail.com> References: <1539086718-4119-1-git-send-email-laoar.shao@gmail.com> <1539086718-4119-2-git-send-email-laoar.shao@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: David Miller , netdev , LKML To: Yafang Shao , Eric Dumazet Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 10/09/2018 06:30 PM, Yafang Shao wrote: > On Tue, Oct 9, 2018 at 11:38 PM Eric Dumazet wrote: >> >> On Tue, Oct 9, 2018 at 7:58 AM Eric Dumazet wrote: >>> >> >>> We do not add bloat in the kernel if no application is ever going to >>> use it, especially in the TCP fast path. >>> >> >> BTW, are you willing to change all memory allocations in the kernel as well ? >> >> Let say an application is using a system call providing a pathname >> (open(), stat(), ...), how this system call >> is going to ask the kernel for no direct reclaim ? >> >> Even allocating a socket with socket() or accept() has no ability to >> avoid direct reclaim. >> >> So tcp_sendmsg() is only the tip of the iceberg. > > If we can really find a solution that is good enough to hanlde direct > reclaim in tcp_sendmsg, > we could also implement it in other syscalls. > Unexpected latency is hateful. We have thousands of other places in the kernel, I want to find a generic solution, not patch all the places one by one. So come back when you have something more generic, and once applications have a way to handle gracefully (without calling sendmsg() in infinite loop ...) to these memory allocation issues. How is EPOLLOUT going to be generated ?