ring the sdiag_protocol to be zero.
>
> The file /proc/net/netlink doesn't provide enough information for
> dumping netlink sockets. It doesn't provide dst_group, dst_portid,
> groups above 32.
>
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Pavel
On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
> On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
I suppose I had wondered along similar lines, but in a slightly
different direction: would the use of a /proc interface to get the
queued signals make some sense?
>>>
>>> I think th
>>> Process checkpointing needs to bite the bullet and
>>> create its own API instead.
>>
>> This is bad approach as well. What we should do is come up with a sane
>> API that makes sense without the checkpoint-restore project _when_
>> _possible_.
>
> Coming up with a sane API in general isn't e
] http://permalink.gmane.org/gmane.linux.kernel.mm/91428
Signed-off-by: Pavel Emelyanov
---
arch/x86/include/asm/pgtable.h | 14 +++-
arch/x86/include/asm/pgtable_types.h |6 +++
fs/proc/task_mmu.c | 59 ---
mm/Kconfig
> + for (i = 0; i < arg.nr; i++) {
> + off = arg.off + i;
> +
> + spin_lock_irq(&child->sighand->siglock);
> + list_for_each_entry(q, &pending->list, list) {
> + if (!off--) {
> + copy_siginfo(&info, &q->info);
On 02/19/2013 04:15 PM, Michael Kerrisk (man-pages) wrote:
> On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin wrote:
>> This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
>>
>> This request is used to retrieve information about a signal with the
>> specified sequence number. A siginfo_t structu
On 02/19/2013 11:34 PM, Oleg Nesterov wrote:
> On 02/19, Pavel Emelyanov wrote:
>>
>> On 02/19/2013 04:15 PM, Michael Kerrisk (man-pages) wrote:
>>> On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin wrote:
>>>> This patch adds a new ptrace request PTRACE_PEEKSIGINF
Hello, everyone!
As was planned, the v0.4 of C/R tools is out, right after the Linux v3.8.
The most valuable thing in this release, is that all the kernel patches
we had are now merged, and thus what crtools-v0.4 can do will work on
the upstream kernel (properly configured)!
Another notable feat
On 02/21/2013 02:37 AM, Oleg Nesterov wrote:
> On 02/19, Pavel Emelyanov wrote:
>>
>> On 02/19/2013 11:34 PM, Oleg Nesterov wrote:
>>> But, given that every PEEK does list_for_each() until it finds the
>>> necessary sequence number, I am wondering how this O(n**2)
On 02/21/2013 05:21 AM, Matthew Helsley wrote:
> On Thu, Feb 14, 2013 at 8:18 AM, Pavel Emelyanov wrote:
>> Hi.
>>
>> I'm working on the checkpoint-restore project (http://criu.org), briefly
>> it's aim is to collect information about process' state and
Hi.
Here's another approach to address the problems with insufficient API
of posix timers.
Currently kernel doesn't provide any API for getting information about
what timers are currently created by process and in which state they
are. Initially the proposal was to add a couple of system calls
ill be increasing on each iteration till INT_MAX and then dropped to zero:
while(1) {
id = timer_create(...);
timer_delete(id);
}
In this version the helpers from include/linux/hashtable.h are used
instead of hand-made hash-table.
Signed-off-by: Pavel Emelyanov
---
include/li
l lines to allow for future
extending.
Each new timer entry starts with the
ID:
line which is added by this patch.
Signed-off-by: Pavel Emelyanov
---
fs/proc/base.c | 83
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git
ion is enough to understand ho the timer_create()
was called for each particular timer.
Signed-off-by: Pavel Emelyanov
---
fs/proc/base.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index fc73d19..7f01e19 100644
---
Adrian Bunk wrote:
> sysctl_tr_rif_timeout can now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> ---
> e5accd81b924224d40a3f38204c08cf6896ed79b
> diff --git a/net/802/tr.c b/net/802/tr.c
> inde
Adrian Bunk wrote:
> struct ipv4_devconf can now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> ---
>
> include/linux/inetdevice.h |2 --
> net/ipv4/devinet.c |2 +-
>
Adrian Bunk wrote:
> This patch makes the needlessly global nf_ct_path[] static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Thanks, Adrian!
> ---
> 6396fbcebe3eb61f7e6eb1a671920a515912b005
&
Adrian Bunk wrote:
> Commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
> ("[RAW]: Consolidate proc interface.") did not only change raw6_seq_ops
> (including adding 3 EXPORT_SYMBOL_GPL's to net/ipv4/raw.c for accessing
> functions from there), it also removed the only user of raw6_seq_ops...
The co
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> Kirill Korotaev wrote:
>>> Cedric Le Goater wrote:
>>>> Hello Kirill !
>>>>
>>>> Kirill Korotaev wrote:
>>>>> Pierre,
>>>>>
>>>>> my point
There's only one caller left - the kill_pgrp one - so merge
these two functions and forget the kill_pgrp_info one.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Reviewed-by: Oleg Nesterov <[EMAIL PROTECTED]>
---
include/linux/sched.h |1 -
kernel/sign
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
kernel/signal.c | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index cc45a6b..a805c74 100644
-
Kirill Korotaev wrote:
>
> Cedric Le Goater wrote:
>> Hello Kirill !
>>
>> Kirill Korotaev wrote:
>>> Pierre,
>>>
>>> my point is that after you've added interface "set IPCID", you'll need
>>> more and more for checkpointing:
>>> - "create/setup conntrack" (otherwise connections get dropped),
>>>
This is an attempt to kill two birds with one stone.
First, we kill one more user of kernel_thread, which is scheduled
for removal. Second - we kill one of the last users of kill_proc -
the function which is also to be removed, because it uses a pid_t
which is not safe now.
Signed-off-by: Pavel
Duncan Sands wrote:
> Hi Pavel,
>
>> Oh, I see. You're right - this race is possible... I'll fix that up
>> if this patch works.
>
> it seems to work fine. Thanks again for doing this!
Oh, thanks for testing. What should I do next to get this into
mainline? Send it to Andrew with you in Cc, or
This function doesn't change the ret's value and thus always
returns 0, with a single exception of returning -EAGAIN
explicitly.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
kernel/signal.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/k
This makes the code more readable, due to less brackets and
small letters in name.
I also move it above the send_signal() as a preparation for
the 3rd patch.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
kernel/signal.c | 12 +++-
1 files changed, 7 insertions
ments and spell-check them.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
kernel/signal.c | 37 +++--
1 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 384d188..f98ec5f 100644
--- a/kernel/sig
the proc is mounted in order not to lose your
/etc/sysctl.conf configuration (and optionally fstab).
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 1c81c8f..47dec4b
gt; Signed-off-by: Cyrill Gorcunov
> CC: Al Viro
> CC: Alexey Dobriyan
> CC: Andrew Morton
> CC: Pavel Emelyanov
> CC: James Bottomley
> ---
> fs/proc/fd.c | 133
> +--
> 1 file changed, 85 insertions(
> +static int prep_fdinfo_driver(struct proc_fdinfo_extra *extra)
> +{
> + struct proc_fdinfo_driver *s;
> +
> + down_read(&fdinfo_drivers_sem);
> + list_for_each_entry(s, &fdinfo_drivers, list) {
> + if (s->probe(extra->f_file)) {
> + extra->driver = s;
>>> +static void *seq_next(struct seq_file *m, void *p, loff_t *pos)
>>> +{
>>> + struct proc_fdinfo_extra *extra = m->private;
>>> + void *v = NULL;
>>> +
>>> + if (extra->driver) {
>>> + int ret = 0;
>>> +
>>> + if (*pos == 0) {
>>> + v = extra->driver-
On 07/30/2012 02:42 PM, richard -rw- weinberger wrote:
> On Mon, Jul 23, 2012 at 10:53 AM, Pavel Emelyanov wrote:
>> This project is an attempt to implement the checkpoint-restore functionality
>> for processes and containers without driving too much code into the kernel
>>
On 07/31/2012 12:57 PM, richard -rw- weinberger wrote:
> On Tue, Jul 31, 2012 at 10:53 AM, Pavel Emelyanov wrote:
>> On 07/30/2012 02:42 PM, richard -rw- weinberger wrote:
>>> On Mon, Jul 23, 2012 at 10:53 AM, Pavel Emelyanov
>>> wrote:
>>>> This
On 07/31/2012 01:29 PM, richard -rw- weinberger wrote:
> On Tue, Jul 31, 2012 at 11:07 AM, Pavel Emelyanov wrote:
>> Sorry :( However, if you can help with patches on that issue that would be
>> highly appreciated :)
>>
>
> Yeah, but I fear it's not that easy.
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 s
On 07/11/2013 10:46 PM, Andy Lutomirski wrote:
>
> Sorry I'm late to the party -- I didn't notice this until the lwn
> article this week.
>
> How does this get munmap + mmap right? mremap marks things soft-dirty,
> but unmapping and remapping seems like it will result in the soft-dirty
> bit bei
On 10/04/2013 11:02 PM, Naoya Horiguchi wrote:
> This flag shows that soft dirty bit is not enabled yet.
> You can enable it by "echo 4 > /proc/pid/clear_refs."
The comment is not correct. Per-VMA soft-dirty flag means, that
VMA is "newly created" one and thus represents a new (dirty) are
in task'
On 10/08/2013 02:12 PM, Janani Venkataraman1 wrote:
>
>
>
>
> From: Pavel Emelyanov
> To: Janani Venkataraman1/Ind
Hi, all!
The checkpoint-restore tool v0.7 release is ready and out,
the changelog is at http://criu.org/Download/criu/0.7
the sources are at http://download.openvz.org/criu/criu-0.7.tar.bz2
The main news about the release is that the ptrace extension to get/set sigmask
on processes and the
On 10/22/2012 11:29 PM, Andrew Morton wrote:
> On Mon, 22 Oct 2012 23:14:52 +0400
> Cyrill Gorcunov wrote:
>
>> Hi guys, during c/r sessions we've found that there is no way at
>> the moment to fetch some VMA associated flags, such as mlock()
>> and madvise(), thus the patches in this series into
Hi!
The Linux-v3.7 is out, and it's good time to release the next version
of the checkpoint-restore tool.
This is mostly bugfix and improvements release, however it's worth
mentioning some new interesting features
* Proper COW mappings handling
Now anonymous private mappings are not COW-ed
On 11/14/2012 10:46 AM, Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 02:38:08PM -0800, Andrew Morton wrote:
>> On Tue, 13 Nov 2012 12:00:32 +0400
>> Cyrill Gorcunov wrote:
>>
Dumb question: do we really need inotify_inode_mark.fhandle at all?
What prevents us from assembling this in
On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
>> On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
> You could not use a pointer and then allocate your buffers on the
> check
> point operation, freeing on rest
On 11/14/2012 02:38 PM, Tvrtko Ursulin wrote:
> On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
>> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
>>> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
>>>> On Wed, Nov 14, 2012 at 09:50:55
>>> How much space does a typical file system need to encode a handle? Am I
>>> right that for must it is just a few bytes? (I just glanced at the code
>>> so I might be wrong.) In which case, could the handle buffer be allocated
>>> dynamically depending on the underlying filesystem? Perhaps addin
s after checkpoint.
>
> To simplify the code we add show_fdinfo callback inside
> struct file_operations (as Al and Pavel are proposing).
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pavel Emelyanov
> CC: Oleg Nesterov
> CC: Andrey Vagin
> CC: Al Viro
> CC: Alexey Dobr
> This allow us to print out raw counter value.
> The /proc/pid/fdinfo/fd output is
>
> | pos: 0
> | flags: 04002
> | eventfd-count: 5a
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pavel Emelyanov
> CC: Oleg Nesterov
> CC: Andrey V
de_fh itself.
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pavel Emelyanov
> CC: Oleg Nesterov
> CC: Andrey Vagin
> CC: Al Viro
> CC: Alexey Dobriyan
> CC: Andrew Morton
> CC: James Bottomley
> CC: "Aneesh Kumar K.V"
> CC: Alexey Dobriyan
> CC: Mat
> [avagin@: fix for unitialized ret variable]
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pavel Emelyanov
> CC: Oleg Nesterov
> CC: Andrey Vagin
> CC: Al Viro
> CC: Alexey Dobriyan
> CC: Andrew Morton
> CC: James Bottomley
> CC: "Aneesh Kumar K.V"
On 11/14/2012 07:19 PM, Cyrill Gorcunov wrote:
> The sigmask is read in lockless manner for a sake of
> code simplicity, thus if precise data needed here
> the tasks which refer to the signalfd should be
> stopped before read.
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pavel
mask:1 ignored_mask:
> 4000
> | fanotify mnt_id: 13 mask:1 ignored_mask: 4000
>
> To minimize impact on general fsnotify code the new functionality
> is gathered in fs/notify/fdinfo.c file.
>
> Signed-off-by: Cyrill Gorcunov
> CC: Pave
r providing the way to use inodes
>> directly when dentry is not available (like in case
>> of inotify system).
>
> Looks OK to me.--b.
Thank you, Bruce!
>>
>> Signed-off-by: Cyrill Gorcunov
>> CC: Pavel Emelyanov
>> CC: Oleg Nesterov
>> CC: Andrey
Initialize TSO state of a skb
> 3. Reset the retransmission time
>
> This patch moves logic from tcp_sendmsg to tcp_write_xmit. A packet
> passes the ussual way, but isn't sent to network. This patch solves
> all described problems and handles tcp_sendpages.
>
> Cc: Pavel
On 12/25/2012 07:27 PM, Oleg Nesterov wrote:
> On 12/25, Oleg Nesterov wrote:
>>
>> And if we add another format we should think
>> twice.
>
> And btw this applies to the whole series.
>
> I guess that probably you actually need DUMP, not DEQUEUE. but the
> latter is not trivial. However, perhaps
As Stephen Rothwell pointed out, config options, that depend on
architecture support, are better to be wrapped into a select +
depends on scheme.
Do this for CONFIG_MEM_SOFT_DIRTY, as it currently works only
for X86.
Signed-off-by: Pavel Emelyanov
Cc: Stephen Rothwell
---
diff --git a/arch
>>> >From that perspective, the dependency on X86 is awful. What's the
>>> problem here and what do other architectures need to do to be able to
>>> support the feature?
>>
>> The problem here is that I don't know what free bits are available on
>> page table entries on other architectures. I was
e]
This var is just not needed.
Signed-off-by: Pavel Emelyanov
---
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index 34d7592..424c2d4 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -154,7 +154,6 @@ static struct k_itimer *__posix_timers_find(stru
Hi, everyone!
Yes, it's that time again! As the Linux-v3.10 is out, we're releasing
the criu-v0.6 to catch up with the recent kernel changes. These includes
posix cpu timers, pending signals and netlink sockets.
As for other new cool features and changes, please visit the
http://criu.org/Download
On 03/11/2013 01:11 PM, Pavel Emelyanov wrote:
> Hi.
>
> Currently kernel doesn't provide any API for getting information about
> what timers are currently created by process and in which state they
> are. Also, the way timer IDs are generated makes it impossible to creat
On 07/27/2013 12:55 AM, Andy Lutomirski wrote:
> On Fri, Jul 26, 2013 at 1:18 PM, Cyrill Gorcunov wrote:
>> Andy reported that if file page get reclaimed we loose soft-dirty bit
>> if it was there, so save _PAGE_BIT_SOFT_DIRTY bit when page address
>> get encoded into pte entry. Thus when #pf happ
On 07/27/2013 11:29 PM, Pavel Emelyanov wrote:
> On 07/27/2013 12:55 AM, Andy Lutomirski wrote:
>> On Fri, Jul 26, 2013 at 1:18 PM, Cyrill Gorcunov wrote:
>>> Andy reported that if file page get reclaimed we loose soft-dirty bit
>>> if it was there, so save _PAGE_B
tore it back.
>
> Reported-by: Andy Lutomirski
> Signed-off-by: Cyrill Gorcunov
> Cc: Pavel Emelyanov
> Cc: Andrew Morton
> Cc: Matt Mackall
> Cc: Xiao Guangrong
> Cc: Marcelo Tosatti
> Cc: KOSAKI Motohiro
> Cc: Stephen Rothwell
> ---
> @@ -57,17 +5
On 07/29/2013 06:14 PM, Cyrill Gorcunov wrote:
> On Mon, Jul 29, 2013 at 06:08:55PM +0400, Pavel Emelyanov wrote:
>>>
>>> - if (!pte_none(*pte))
>>> + ptfile = pgoff_to_pte(pgoff);
>>> +
>>> + if (!pte_none(*pte)) {
>>> +#ifdef C
tore it back.
>
> Reported-by: Andy Lutomirski
> Signed-off-by: Cyrill Gorcunov
Acked-by: Pavel Emelyanov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
e in pte entry where we can
> save the _PTE_SWP_SOFT_DIRTY bit while page is in swap. The
> _PAGE_PSE was chosen for that, it doesn't intersect with swap
> entry format stored in pte.
>
> Reported-by: Andy Lutomirski
> Signed-off-by: Cyrill Gorcunov
Acked-by: Pavel Emelyanov
--
To unsubs
On 08/21/2013 11:07 PM, Andy Lutomirski wrote:
> On Wed, Aug 21, 2013 at 12:03 PM, Cyrill Gorcunov wrote:
>> On Wed, Aug 21, 2013 at 08:50:26PM +0200, H. Peter Anvin wrote:
>>> But is there a manifest bug or not? What is the deal with Xen?
>>>
>>
>> I personally don't see bug here because
>>
>>
On 08/22/2013 04:51 AM, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:04:54PM -0700, Linus Torvalds wrote:
> > On Wed, Aug 21, 2013 at 12:03 PM, Cyrill Gorcunov
> wrote:
> > >
> > > I personally don't see bug here because
> > >
> > > - this swapped page soft dirty bit is set for non-presen
On 08/22/2013 01:32 PM, David Vrabel wrote:
> On 22/08/13 00:04, Linus Torvalds wrote:
>> On Wed, Aug 21, 2013 at 12:03 PM, Cyrill Gorcunov wrote:
>>>
>>> I personally don't see bug here because
>>>
>>> - this swapped page soft dirty bit is set for non-present entries only,
>>>never for prese
ntial future abuse.
>>
>> Also add a comment on _PAGE_SWP_SOFT_DIRTY definition explaining
>> scope of its usage.
>>
>> Signed-off-by: Cyrill Gorcunov
>
> Acked-by: Jan Beulich
Acked-by: Pavel Emelyanov
--
To unsubscribe from this list: send the line "un
e in pte entry where we can
> save the _PTE_SWP_SOFT_DIRTY bit while page is in swap. The
> _PAGE_PSE was chosen for that, it doesn't intersect with swap
> entry format stored in pte.
>
> Reported-by: Andy Lutomirski
> Signed-off-by: Pavel Emelyanov
> Signed-off-by: Cyrill Gorcunov
>
On 07/24/2013 08:23 PM, Andy Lutomirski wrote:
> On Wed, Jul 24, 2013 at 9:08 AM, Cyrill Gorcunov wrote:
>> Andy Lutomirski reported that in case if a page with _PAGE_SOFT_DIRTY
>> bit set get swapped out, the bit is getting lost and no longer
>> available when pte read back.
>
> Potentially sill
On 07/24/2013 10:52 PM, Cyrill Gorcunov wrote:
> On Wed, Jul 24, 2013 at 11:21:46AM -0700, Andy Lutomirski wrote:
>>>
>>> I fear for tracking soft-dirty-bit for swapped entries we sinply have
>>> no other place than pte (still i'm quite open for ideas, maybe there
>>> are a better way which I've mi
On 07/24/2013 11:40 PM, Andy Lutomirski wrote:
> On Wed, Jul 24, 2013 at 12:04 PM, Cyrill Gorcunov wrote:
>> On Wed, Jul 24, 2013 at 10:55:41PM +0400, Pavel Emelyanov wrote:
>>>>
>>>> Well, some part of information already lays in pte (such as 'file' bi
On 07/25/2013 12:26 PM, Hush Bensen wrote:
> On 07/25/2013 03:29 PM, Pavel Emelyanov wrote:
>> On 07/24/2013 11:40 PM, Andy Lutomirski wrote:
>>> On Wed, Jul 24, 2013 at 12:04 PM, Cyrill Gorcunov
>>> wrote:
>>>> On Wed, Jul 24, 2013 at 10:55:41PM +0400, P
On 04/09/2013 03:10 AM, KOSAKI Motohiro wrote:
>> This approach works on any task via it's proc, and can be used on different
>> tasks in parallel.
>>
>> Also, Andrew was asking for some performance numbers related to the change.
>> Now I can say, that as long as soft dirty bits are not cleared, no
On 04/09/2013 02:30 AM, Andrew Morton wrote:
> On Fri, 05 Apr 2013 21:06:12 +0400 Pavel Emelyanov
> wrote:
>
>> Hello,
>>
>> This is another attempt (previous one was [1]) to implement support for
>> memory snapshot for the the checkpoint-restore project (h
This is the resend and (while the iron is hot) the request for merge of
the implementation of the soft-dirty bit concept that should help to track
changes in user memory.
This set differs from what Andrew has sent recently in a single point --
the way pagemap entries' bits are reused (patch #5, an
each other.
This patch:
A new clear-refs type will be added in the next patch, so prepare
code for that.
[a...@linux-foundation.org: don't assume that sizeof(enum clear_refs_types) ==
sizeof(int)]
Signed-off-by: Pavel Emelyanov
Cc: Andrew Morton
Cc: Matt Mackall
Cc: Xiao Guangrong
In the next patch the clear-refs-type will be required in
clear_refs_pte_range funciton, so prepare the walk->private to carry this
info.
Signed-off-by: Pavel Emelyanov
Cc: Andrew Morton
Cc: Matt Mackall
Cc: Xiao Guangrong
Cc: Glauber Costa
Cc: Marcelo Tosatti
Cc: KOSAKI Motohiro
---
These bits are always constant (== PAGE_SHIFT) and just occupy space in
the entry. Moreover, in next patch we will need to report one more bit in
the pagemap, but all bits are already busy on it.
That said, describe the pagemap entry that has 6 more free zero bits.
Signed-off-by: Pavel
s that when mremap moves PTEs they are marked with
soft-dirty as well, since from the user perspective mremap modifies the
virtual memory at mremap's new address.
Signed-off-by: Pavel Emelyanov
Cc: Andrew Morton
Cc: Matt Mackall
Cc: Xiao Guangrong
Cc: Glauber Costa
Cc: Marcelo Tosatti
warned and have time to fix themselves
2. those who use soft-dirty know about new pagemap format
3. some time soon we get rid of any signs of page-shift in pagemap as well as
this trick with clear-soft-dirty affecting pagemap format.
Signed-off-by: Pavel Emelyanov
Cc: Andrew Morton
Cc: Ma
Ladies and Gentlemen,
I'm glad to announce the 5th release of the checkpoint-restore tool!
This release is mostly about the tool itself. The v3.9 kernel, with which the
new CRIU tool should be used, only contains a couple of bug fixes related to
the C/R project and no new related features. As for
On 05/03/2013 03:36 PM, Xiao Guangrong wrote:
> On 05/01/2013 12:12 AM, Pavel Emelyanov wrote:
>
>> +static inline void clear_soft_dirty(struct vm_area_struct *vma,
>> +unsigned long addr, pte_t *pte)
>> +{
>> +#ifdef CONFIG_MEM_SOFT_DIRTY
>> +
address space is about to be changed),
the _invalidate_range_start and _end are used. But for those start
and end are not known exactly. To address this, the same trick as
in exit_mmap() is used -- start is 0 and end is (unsigned long)-1.
Signed-off-by: Pavel Emelyanov
---
diff --git a/fs/proc
On 05/02/2013 09:08 PM, Matt Helsley wrote:
> On Thu, Apr 11, 2013 at 03:29:41PM +0400, Pavel Emelyanov wrote:
>> This file is the same as the pagemap one, but shows entries with bits
>> 55-60 being zero (reserved for future use). Next patch will occupy one
>> of them.
>
significant information about page updates.
Another issue with it -- it was impossible to use one to watch arbitrary
task -- task had to mark memory areas with madvise itself to make events
occur.
Also, program, that monitored the update events could interfere with
anyone else trying to me
A new clear-refs type will be added in the next patch, so prepare
code for that.
Signed-off-by: Pavel Emelyanov
---
fs/proc/task_mmu.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 3e636d8..67c2586 100644
In next patch the clear-refs-type will be required in clear_refs_pte_range
funciton, so prepare the walk->private to carry this info.
Signed-off-by: Pavel Emelyanov
---
fs/proc/task_mmu.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.
These bits are always constant (== PAGE_SHIFT) and just occupy space in
the entry. Moreover, in next patch we will need to report one more bit in
the pagemap, but all bits are already busy on it.
That said, describe the pagemap entry that has 6 more free zero bits.
Signed-off-by: Pavel Emelyanov
This file is the same as the pagemap one, but shows entries with bits
55-60 being zero (reserved for future use). Next patch will occupy one
of them.
Signed-off-by: Pavel Emelyanov
---
Documentation/filesystems/proc.txt |2 ++
Documentation/vm/pagemap.txt |3 +++
fs/proc/base.c
s that when mremap moves PTEs they are marked with
soft-dirty as well, since from the user perspective mremap modifies the
virtual memory at mremap's new address.
Signed-off-by: Pavel Emelyanov
---
Documentation/filesystems/proc.txt |7 +-
Documentation/vm/pagemap.txt |
On 03/25/2013 05:32 PM, Pavel Emelyanov wrote:
> On 03/11/2013 01:11 PM, Pavel Emelyanov wrote:
>> Hi.
>>
>> This v3 series is ported on v3.9-rc2 and patches' changelogs are fixed
>> according to Thomas' feedback to contain info why the change is require
On 04/12/2013 01:19 AM, Andrew Morton wrote:
> On Thu, 11 Apr 2013 15:29:41 +0400 Pavel Emelyanov
> wrote:
>
>> This file is the same as the pagemap one, but shows entries with bits
>> 55-60 being zero (reserved for future use). Next patch will occupy one
>> of them.
On 04/12/2013 01:24 AM, Andrew Morton wrote:
> On Thu, 11 Apr 2013 15:30:00 +0400 Pavel Emelyanov
> wrote:
>
>> The soft-dirty is a bit on a PTE which helps to track which pages a task
>> writes to. In order to do this tracking one should
>>
>> 1. Clear s
It creates a mapping of 3 pages and checks that reads, writes and clear-refs
result in present and soft-dirt bits reported from pagemap2 set as expected.
Signed-off-by: Pavel Emelyanov
---
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 575ef80..827f2c0
ff-by: Pavel Tikhomirov
Acked-by: Pavel Emelyanov
> ---
> fs/proc/base.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 2dad4a9..8a38eef 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2079,
On 05/17/2013 07:59 PM, Greg KH wrote:
> On Fri, May 17, 2013 at 02:12:03AM +0400, Pavel Tikhomirov wrote:
>> Expand information about posix-timers in /proc//timers by adding
>> info about clock, with which the timer was created. I.e. in the forth
>> line of timer info after "notify:" line go "Cloc
On 02/21/2013 10:21 PM, Pavel Emelyanov wrote:
> Hi.
>
> Here's another approach to address the problems with insufficient API
> of posix timers.
Gentlemen,
If you don't mind, I'd like to remind you about this set :) If you could
find some time in your schedule an
Hi.
Currently kernel doesn't provide any API for getting information about
what timers are currently created by process and in which state they
are. Also, the way timer IDs are generated makes it impossible to create
a timer with any desired ID. Both facilities are very very tempting by
the check
1 - 100 of 463 matches
Mail list logo
