Hi guys,
when we do restore files such as eventfd/eventpoll we need to pass
appropriate parameters to system calls. Unfortunately there is no
easy way to retrieve this information from the kernel. So to make
possible to obtain this kind of information the proc/pid/fdinfo/fd
handling code has been modified to print "extra" snippets depending
on file type.
The base idea is to make fdinfo being seq-files and plug-in helpers.
For example eventpoll files together with basic pos/flags now print
out target file descriptor number, events and data associated with
an event:
| pos: 0
| flags: 02
| tfd: 5 events: 1d data: ffffffffffffffff
This series is early draft not for inclusion yet but just to
gather people opinions on idea in general and implementation
details. I tried to make the change as small as I can.
I'm working on fsnotify part at moment but since it's not
yet complete decided to not include this patch, it'll appear
later.
(I've been said that idea of extending fdinfo to provide
additional data snippets was approved on LSF this year.
Am I right, Pavel?)
Any comments and complains are highly appreciated!
Cyrill
> (I've been said that idea of extending fdinfo to provide
> additional data snippets was approved on LSF this year.
> Am I right, Pavel?)
Yes, you are.
> Any comments and complains are highly appreciated!
>
> Cyrill
> .
>
On Thu, 17 May 2012 20:07:38 +0400
Cyrill Gorcunov <[email protected]> wrote:
> when we do restore files such as eventfd/eventpoll we need to pass
> appropriate parameters to system calls.
What does "such as" mean? Provide the whole list, please. I assume
we're going to have to add ~100 lines of stuff to each and every one?
Stuff which, according to this patchset, is needed even when
CONFIG_CHECKPOINT_RESTORE=n?
My reason for disliking our whole approach to integration of c/r is
that it exposes us to an ongoing trickle of nasty surprises. This
patchset is one such nasty surprise, and we don't even know how
extensive this particular surprise will be.
And how many more surprises are we going to get?
I'm quite apprehensive about this, largely because it has so many
unknowns. How much work would it be to prepare a full list of
everything that still needs to be done to fully implement c/r in Linux?
On Thu, May 17, 2012 at 12:05:41PM -0700, Andrew Morton wrote:
> On Thu, 17 May 2012 20:07:38 +0400
> Cyrill Gorcunov <[email protected]> wrote:
>
> > when we do restore files such as eventfd/eventpoll we need to pass
> > appropriate parameters to system calls.
>
> What does "such as" mean? Provide the whole list, please. I assume
> we're going to have to add ~100 lines of stuff to each and every one?
> Stuff which, according to this patchset, is needed even when
> CONFIG_CHECKPOINT_RESTORE=n?
By such as I meant eventfd/eventpoll and fsnotify. And Andrew, I don't
know the whole list yet, if I knew it I would definitely share it. But
as I said I'm trying really hard to minimize patch impact on mainline kernel.
With this particular set (well, inotify part needed, but I didn't send
it out yet simple because I find it not well done for mainline inclusion,
but its draft variant lives in our kernel repo on github and I'm using
it alot for testing c/r on various programs) we're able to c/r crond/httpd.
And I didn't wrap this code with CONFIG_CHECKPOINT_RESTORE yet to
simplify the patch and gather people opinion on design in general.
I'll add it later (don't worry I remember about it).
Still plain conversion of fdinfo to seq-files and move code to fd.c
I think is an improvement in readability (the proc/base.c is a _way_
big file and I think it should be splitted by small steps).
> My reason for disliking our whole approach to integration of c/r is
> that it exposes us to an ongoing trickle of nasty surprises. This
> patchset is one such nasty surprise, and we don't even know how
> extensive this particular surprise will be.
Why it's nasty? We gather back information from kernel needed for
use with syscalls to restore kernel entities (in case of this patchset
we restore eventfd and eventpolls).
> And how many more surprises are we going to get?
>
> I'm quite apprehensive about this, largely because it has so many
> unknowns. How much work would it be to prepare a full list of
> everything that still needs to be done to fully implement c/r in Linux?
Well, to build the whole list... hmm, I think I need to talk to Pavel.
Cyrill
On 05/17/2012 11:05 PM, Andrew Morton wrote:
> On Thu, 17 May 2012 20:07:38 +0400
> Cyrill Gorcunov <[email protected]> wrote:
>
>> when we do restore files such as eventfd/eventpoll we need to pass
>> appropriate parameters to system calls.
>
> What does "such as" mean? Provide the whole list, please.
As far as this particular set is concerned -- we'll add inotify stuff
there and the signalfd info a bit later (no apps we test use it by now).
That's it. But once there will appear more fd-s based on anon_inode
and that are configured using custom syscalls, we'll have to implement
the "get info" API for them too.
> I assume we're going to have to add ~100 lines of stuff to each and
> every one? Stuff which, according to this patchset, is needed even when
> CONFIG_CHECKPOINT_RESTORE=n?
Generally speaking -- yes. It can be useful to check e.g. what the event
counter is on some eventfd for debugging purposes. Right now there's no
way for getting this info.
> My reason for disliking our whole approach to integration of c/r is
> that it exposes us to an ongoing trickle of nasty surprises. This
> patchset is one such nasty surprise, and we don't even know how
> extensive this particular surprise will be.
Well, I wouldn't say it's nasty. The problem with evetpoll, eventfd and
inotifies, is that each of them is a set-only API unlike most of the other
APIs for working with fds. I.e. -- you can configure your fd, it will work,
yes. But you have NO MEANS for finding out what you have configured
previously. What we do is just make the API complete.
If you believe that using fdinfo file in proc for that is nasty, then we're
OK to rework this. But this approach was discussed on LSF this year, that's
why we've implemented it this way.
> And how many more surprises are we going to get?
>
>
> I'm quite apprehensive about this, largely because it has so many
> unknowns. How much work would it be to prepare a full list of
> everything that still needs to be done to fully implement c/r in Linux?
I'd say, that the whole c/r project is being done to determine how much
information the kernel does NOT provide yet. And we really appreciate that
this happens on the mainstream kernel, rather than in a separate branch.
> .
>
Thanks,
Pavel