Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <CAFE37chiT0PnjxW1sk92ZNf2jdv+6-vYoZ=-gXTyis44G1BChg@mail.gmail.com>
References: <alpine.GSO.2.20.1702011839170.17193@hatchepsut.acc.umu.se>
 <a0a55e81-f532-0eff-30e5-bd5b197dc672@gmail.com> <CAKQ1sVPfCFXAAPWADzaUp_VhLC8KF=Ub5bCQQBO=hze37iNMww@mail.gmail.com>
 <CAKQ1sVP0du2cLuxoky4y+HV7rKLM9txpAb4HA8mbwSBMDx7TEA@mail.gmail.com>
 <2B733D2A-F05D-4857-9434-721A9AE78CF8@greenbytes.de> <CAKQ1sVP8njX=HvyS7vc4eC7+_vconLk15mq+2DuUMbej+QY73Q@mail.gmail.com>
 <CAKQ1sVPJVJq9Z69f-B9C2mnyX1Y7xyY7GYzSxVf17=EzoTKaSQ@mail.gmail.com>
 <CAKQ1sVP57ALufNgSLng0OhkMe7bgq+3qecw__VYeRhAwVQBvLQ@mail.gmail.com>
 <30d3bd5d-48cf-770f-53c8-b4ec279da2bd@gmail.com> <alpine.GSO.2.20.1702192212351.26208@hatchepsut.acc.umu.se>
 <712ee78b-179f-1381-7aec-ad9d9ccb9334@gmail.com> <E561ABCC-BB27-4960-8AF5-6F9E98602307@greenbytes.de>
 <2450d64e-cfed-08b9-c995-4a5937753511@gmail.com> <CAKQ1sVNbgNzAhBe90M7Q+0swv_GX+MfhPLte76frQb+9SsEq9Q@mail.gmail.com>
 <9DF9D902-5357-496E-A597-DB5130D50E06@greenbytes.de> <CAKQ1sVMCDocS4WMtLKbERUZW_KoWoJxcBG8B6a-W56OYvnKmrw@mail.gmail.com>
 <e1814998-26ee-1c5d-b01b-76391f931d44@gmail.com> <CAFE37chiT0PnjxW1sk92ZNf2jdv+6-vYoZ=-gXTyis44G1BChg@mail.gmail.com>
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Fri, 24 Feb 2017 01:48:14 +0100
Message-ID: <CAKQ1sVNQAY2HO920_5ZS4jWm6Xso=2qBb2-nNAyHDAmKetsGpQ@mail.gmail.com>
Subject: Re: httpd 2.4.25, mpm_event, ssl: segfaults
To: httpd-dev <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 24 Feb 2017 00:48:24 -0000

On Thu, Feb 23, 2017 at 10:06 PM, Daniel Lescohier
<daniel.lescohier@cbsi.com> wrote:
> Why would high-order memory allocations be a problem in userspace code,
> which is using virtual memory?  I thought high-order allocations is a big
> problem in kernel space, which has to deal with physical pages.

Well, both in kernel or user space, the difficulty is finding large
contiguous memory.

With virtual memory (admittedly virtually larger than physical
memory), it needs more "active" regions to fail, but still it can fail
if many heterogeneous chunks are to be mapped at a time, the OOM
killer will do its job.

It depends on how closed to the resident memory limit you are of
course (it won't happen if some memory can be compressed or swapped),
but large chunks are no better with lot of RAM either.

>
> But when you write to a socket, doesn't the kernel scatter the userspace
> buffer into multiple SKBs?  SKBs on order-0 pages allocated by the kernel?

Right, in Linux network stack (or drivers) is mainly using (or is
moving to) order 0 or 1 chunks (with scatterlists when needed).

But this is where httpd's job end, we talk about before this here :)

From the other message:

On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote:
>
> IOW:
> read():Three copies: copy from filesystem cache to httpd read() buffer to
> encrypted-data buffer to kernel socket buffer.

Not really, "copy from filesystem cache to httpd read() buffer" is
likely mapping to userspace, so no copy (on read) here.

> mmap(): Two copies: filesystem page already mapped into httpd, so just copy
> from filesystem (cached) page to encrypted-data buffer to kernel socket
> buffer.

So, as you said earlier the "write to socket" isn't a copy either,
hence both read() and mmap() implementations could work with a single
copy when mod_ssl is involved (this is more than a copy but you
counted it above so), and no copy at all without it.


Regards,
Yann.