Messages in this thread | | | Date | Wed, 11 Jan 2012 23:36:16 +0400 | From | Pavel Emelyanov <> | Subject | Re: [RFC] on general object IDs again |
| |
On 01/11/2012 11:29 PM, KOSAKI Motohiro wrote: >>>> 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. > > Why O(N^2) is matter? Typical HPC system have mere a few hundred pids. > so, O(N^2) > is not slow. How do you mesure Andrew's proposal? > > If you have 1000 pids and each syscall need 10usec, > > 1000 * 1000 * 10 = 10,000,000usec = 10sec. But, important thing is, almost all > processes don't share fs, mm and other structs. then, if we check > reference count > before task traversal, required time may reduce 1/10x - 1/100x.
This might work for mm_structs, although quite a lot apps now do have threads and this mm->users check will be negative. But how about open files? Once we entered the get-the-youngest-file-owner routine we need to take locks and with 1000 tasks the overhead is not 1000 syscalls, but 1000 (syscalls + locks).
> >> But when we get a number of pids to dump we need the >> resource affinity picture over them all. > . >
| |