netdev - Re: [PATCH resend] net: sock: Add option for memory optimized hints.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57640BA7.8010304@sonymobile.com>
Date:	Fri, 17 Jun 2016 16:39:35 +0200
From:	peter enderborg <peter.enderborg@...ymobile.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"open list:PTP HARDWARE CLOCK SUPPORT" <netdev@...r.kernel.org>
Subject: Re: [PATCH resend] net: sock: Add option for memory optimized hints.

On 06/17/2016 04:14 PM, Eric Dumazet wrote:
> On Fri, 2016-06-17 at 15:58 +0200, peter enderborg wrote:
>> From: Peter Enderborg <peter.enderborg@...ymobile.com>
>>
>> When sending data the socket allocates memory for
>> payload on a cache or a page alloc. The page alloc
>> then might trigger compation that takes long time.
>> This can be avoided with smaller chunks. But
>> userspace can not know what is the right size for
>> the smaller sends. For this we add a SIZEHINT
>> getsocketopt where the userspace can get the size
>> for send that will fit into one page (order 0) or
>> the max for a slab cache allocation.
>
> For which kind of sockets exactly you hit a problem ?
>
> Sorry, this patch is probably not helping in any way.
>
It is mainly for af_unix sockets, and the effect is
quite significant when you hit a compaction, or with
this patch avoid get in to compaction, but it
can also be used for reducing the pressure on memory
for tcp. And the patches you suggested have been
applied (with the addition "af_unix: fix bug on large send()")
I see that there is a lot of other compaction fixes
recently but the problem are still there. And of course
to make any difference you need to change your
userland application too. But in our Qualcomm/Google
bastard to kernel. It makes a huge difference on the
behaviour of send(). But I also does not see this as
perfect solution. A wake-up function that has
the buffers reserved would be better.Or a pre allocated
send buffer would also be better. But I dont expect that
linux will have a real-time socket implementation in
near future.