Adjustments to container logging to address concerns from #262

[portante]

There are two commits in this PR:

---

Move WRITEV_BUFFER_N_IOV to src/ctr_logging.c

The WRITEV_BUFFER_N_IOV constant is not part of the ctr_logging interface, and is only used internal to src/ctr_logging.c.

---

Match read(2) buffer size to pipe size.

Address a number of conditions flagged in issue #262.

The general thrust of this commit is to move closer to a one-to-one, read(2) system call to writev(2) system call ratio by creating a memory buffer for reading sized to match the stdio pipes.

The commit also allocates a maximum number of I/O vectors sized to the read buffer size, calculating 2 I/O vectors per line, defaulting to a target line size of 25 bytes (defined as the constant, AVG_LOG_LINE_TARGET).

The commit also now allocates the I/O vectors and read buffer memory using mmap() so that we don't cross page boundaries for I/O operations.

As a result, the commit removes the STDIO_BUF_SIZE constance, using fcntl(F_GETPIPE_SZ) calls to size all buffers for reading from pipes.

The stdpipe_t value is now passed to write_to_remote_consoles() so that we do not have to play games with pre-/post- byte allocations to buffers.

[haircommander]

I opened cri-o/cri-o#5013 to test these changes with the kubernetes e2e and cri-o

[rhatdan]

Seems to be some packaging issues:
/usr/bin/ld: src/ctr_logging.o: in function writev_buffer_init': ctr_logging.c:(.text+0xd5a): undefined reference to ceilf'
/usr/bin/ld: ctr_logging.c:(.text+0xdd9): undefined reference to `ceilf'

Also fmt test is not happy.

[jnovy]

@portante Thank you for raising this - the most of the performance issues in your PR still applies even in the current conmon code base. Are you planning to update your PR? If not, I can create a new one.

[portante]

Thanks @jnovy, I'll take a stab at updating this PR.

We really should consider shedding all this in favor of NOT interpreting the data stream of logs but instead write out what is read from the pipe, deferring its interpretation to when it is read. See cri-o/cri-o#1605.

That would both solve the performance problem, while removing the ability of the data stream content to negatively impact the behavior of conmon. I am not aware of another operating system interface where that kind of impact is allowed (e.g., the Linux kernel does not read the contents of a write(2) system call and change its behavior).

[jnovy]

@portante Perfect, let me know once it's ready for review. I appreciate your effort.