> [2015-02-19T00:08:01+0530]: "Nicholas Mc Guire" (nicholas-mcguire):
nicholas-mcguire> On Wed, 18 Feb 2015, Greg KH wrote:
,[ greg-kh ]
| As proof of this, there was a test of the kernel a year or so ago that
| measured the placement of the existing likely/unlikely markers in the
| kerne
Hi Greg,
There is plan to move to 3.14, right now the focus it to iron out
existing issues.
Now with regard to core dump issue, we find 10% of times we get struck in
coredump_wait():
==> wait_for_completion(&core_state->startup);
Analyzing exit_mm() to see what is going wrong here.
I have one
Hello
Proces have a established tcp socket. It calls sys_revcmsg on that
socket. That function goes all the way to tcp_recvmsg function.
Function tcp_recvmsg.c (defined in net/ipv4/tcp.c) blocks it self on
function sk_wait_data if socket recv queue is empty. I wanted to know
how socked is checked
On Thu, 19 Feb 2015 23:45:44 +0100, Grzegorz Dwornicki said:
> How does the kernel know when to "unblock" the process? Function name:
> sk_wait_data and macro name: sk_wait_event tells me that there should
> be some queue checning from time to time...
No need to check the queue from time to time.
Hi
On Thu, Feb 19, 2015 at 3:45 PM, Grzegorz Dwornicki wrote:
> Hello
>
> Proces have a established tcp socket. It calls sys_revcmsg on that
> socket. That function goes all the way to tcp_recvmsg function.
>
> Function tcp_recvmsg.c (defined in net/ipv4/tcp.c) blocks it self on
> function sk_wai
