ia/IBM@IBMIN,
> Cc: , ,
> , ,
> , ,
> , ,
> , ,
> , ,
> , , ,
> , ,
> , , ,
> , ,
> ,
> Date: 10/04/2013 04:08 PM
> Subject: Re: [RFC] [PATCH 00/19] Non disruptive application core dump
> infrastructure using task_work_add()
>
>
>
> On 10/04/2013 02:30
: [RFC] [PATCH 00/19] Non disruptive application core dump
infrastructure using task_work_add()
On 10/04/2013 02:30 PM, Janani Venkataraman wrote:
Hi all,
This series is based on the Task work add approach. We didn't adopt the
CRIU
approch because of the following reasons
...@redhat.com,
epa...@redhat.com, d.hatay...@jp.fujitsu.com,
james.ho...@imgtec.com, a...@linux-foundation.org,
torva...@linux-foundation.org
Date: 10/08/2013 12:26 AM
Subject:Re: [RFC] [PATCH 00/19] Non disruptive application core dump
: [RFC] [PATCH 00/19] Non disruptive application core dump
infrastructure using task_work_add()
On 10/04/2013 02:30 PM, Janani Venkataraman wrote:
> Hi all,
>
> This series is based on the Task work add approach. We didn't adopt the
CRIU
> approch because of the follo
,
ava...@openvz.org, o...@redhat.com, epa...@redhat.com,
d.hatay...@jp.fujitsu.com, james.ho...@imgtec.com,
a...@linux-foundation.org, torva...@linux-foundation.org
Date: 10/04/2013 04:08 PM
Subject:Re: [RFC] [PATCH 00/19] Non disruptive application core dump
...@openvz.org, ava...@openvz.org, o...@redhat.com,
epa...@redhat.com, d.hatay...@jp.fujitsu.com,
james.ho...@imgtec.com, a...@linux-foundation.org,
torva...@linux-foundation.org
Date: 10/08/2013 12:26 AM
Subject:Re: [RFC] [PATCH 00/19] Non disruptive
Hello,
On Fri, Oct 04, 2013 at 02:38:43PM +0400, Pavel Emelyanov wrote:
> > * It is not upstream yet.
>
> It is, starting from criu-v0.7 + linux-3.11
>
> > * There are concerns about the security of the dump.
>
> Can you elaborate on this? Is it fixable in CRIU at all?
>
> > * It involves a
> > Couldn't they just use the new process_vm_readv() syscalls instead?
> > AFAIK those do not require ptrace.
> >
> We need the register set and hence would need a ptrace.
But the kernel needs to stop to to read the registers.
Do you have data how much the latency difference is between
an
On 10/07, Suzuki K. Poulose wrote:
>
> On 10/04/2013 07:14 PM, Andi Kleen wrote:
>
> > Couldn't they just use the new process_vm_readv() syscalls instead?
> > AFAIK those do not require ptrace.
> >
> We need the register set and hence would need a ptrace.
Or the task itself can dump its
On 10/04/2013 07:14 PM, Andi Kleen wrote:
> On Fri, Oct 04, 2013 at 04:00:12PM +0530, Janani Venkataraman wrote:
>> Hi all,
>>
>> The following series implements an infrastructure for capturing the core of
>> an
>> application without disrupting its process.
>
> The problem is that gcore et.al.
On 10/04/2013 07:14 PM, Andi Kleen wrote:
On Fri, Oct 04, 2013 at 04:00:12PM +0530, Janani Venkataraman wrote:
Hi all,
The following series implements an infrastructure for capturing the core of
an
application without disrupting its process.
The problem is that gcore et.al. have to stop
On 10/07, Suzuki K. Poulose wrote:
On 10/04/2013 07:14 PM, Andi Kleen wrote:
Couldn't they just use the new process_vm_readv() syscalls instead?
AFAIK those do not require ptrace.
We need the register set and hence would need a ptrace.
Or the task itself can dump its
Couldn't they just use the new process_vm_readv() syscalls instead?
AFAIK those do not require ptrace.
We need the register set and hence would need a ptrace.
But the kernel needs to stop to to read the registers.
Do you have data how much the latency difference is between
an optimized
Hello,
On Fri, Oct 04, 2013 at 02:38:43PM +0400, Pavel Emelyanov wrote:
* It is not upstream yet.
It is, starting from criu-v0.7 + linux-3.11
* There are concerns about the security of the dump.
Can you elaborate on this? Is it fixable in CRIU at all?
* It involves a lot of
On Fri, Oct 04, 2013 at 04:00:12PM +0530, Janani Venkataraman wrote:
> Hi all,
>
> The following series implements an infrastructure for capturing the core of
> an
> application without disrupting its process.
The problem is that gcore et.al. have to stop the process briefly
to attach and then
On 10/04/2013 02:30 PM, Janani Venkataraman wrote:
> Hi all,
>
> This series is based on the Task work add approach. We didn't adopt the CRIU
> approch because of the following reasons:
>
> * It is not upstream yet.
It is, starting from criu-v0.7 + linux-3.11
> * There are concerns about the
Hi all,
The following series implements an infrastructure for capturing the core of an
application without disrupting its process.
So ideally what we are trying to do is to export the infrastructure using
/proc/pid/core. Reading the file would give an ELF Format core-dump at that
instant
Hi all,
The following series implements an infrastructure for capturing the core of an
application without disrupting its process.
So ideally what we are trying to do is to export the infrastructure using
/proc/pid/core. Reading the file would give an ELF Format core-dump at that
instant
On 10/04/2013 02:30 PM, Janani Venkataraman wrote:
Hi all,
This series is based on the Task work add approach. We didn't adopt the CRIU
approch because of the following reasons:
* It is not upstream yet.
It is, starting from criu-v0.7 + linux-3.11
* There are concerns about the
On Fri, Oct 04, 2013 at 04:00:12PM +0530, Janani Venkataraman wrote:
Hi all,
The following series implements an infrastructure for capturing the core of
an
application without disrupting its process.
The problem is that gcore et.al. have to stop the process briefly
to attach and then use
20 matches
Mail list logo