Messages in this thread |  | | | Date | Wed, 11 Jan 2012 22:31:15 +0400 | | From | Cyrill Gorcunov <> | | Subject | Re: [RFC] on general object IDs again |
| |
On Wed, Jan 11, 2012 at 10:22:29PM +0400, Pavel Emelyanov wrote: > On 01/11/2012 10:19 PM, KOSAKI Motohiro wrote: > >> Hi Kosaki, > >> > >> the idea on user-space is something like > >> > >> - collect all pids to dump > >> - collect IDs for every pid > >> - sort the IDs obtained > >> - find the same IDs (which will be kind of find intersections in a sets of IDs) and > >> set up CLONE_ flags on restore procedure as appropriate (for example if > >> GEN_OBJ_ID_VM IDs for two or more tasks are the same we need to use CLONE_VM > >> at restore time, and so on). > > > > Then, you only need to compare. not any other calculation. i.e. only > > need id uniqueness. > > And any resource are referenced from tasks. so, can you reuse pid for > > this? example, > > two taska share one mm. > > > > task-a(pid: 100) > > |-----------------mm > > task-b(pid: 200) > > > > > > gen_obj_id(task-b, GEN_OBJ_ID_VM) return 100. (youngest pid of referenced tasks) > > We can, but determining the youngest pid for an mm struct is O(N) algo. > Having N tasks with N mm_structs getting the sharing picture becomes O(N^2). >
Yeah, exactly. If not the speed problem we would simply stick with Andrew's proposal as two-id-are-the-same(pid1, pid2) syscall. But when we get a number of pids to dump we need the resource affinity picture over them all.
Cyrill
|  |