Hi,
sorry for the really delayed mail..
On May 28 2007 22:53, Eric W. Biederman wrote:
>> Jan Engelhardt writes:
>>> On Apr 10 2007 17:47, Jan Engelhardt wrote:
>>>
>>> Done that and the result is that `ps afwx` now looks like:
>>>
>>> PID TTY STAT TIME COMMAND
>>> 2722 ?S
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On 5/29/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> "Albert Cahalan" <[EMAIL PROTECTED]> writes:
>
> That's not what I mean. (the "-e" causes that of course)
> I'm asking about the parent-child relationships shown.
> The "-H" option is a bit d
On 5/29/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> Jan Engelhardt writes:
-if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u')
+if(ADOPTED(processes[i]) && forest_type!='u')
That's not compatible because init's children ar
> Having the kernel not reparent user processes to init is an interesting
> idea, especially when those processes have not existed. I'm not
> certain that is POSIX complaint and otherwise backwards compatible.
It's hard to see how it would work. There has to be some parent PID. The
reason using
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> This has long been rotten. Mind fixing it for us? :-)
>
> We have N types of thread on M CPUs. Pick something, N or M,
> to be at the top level in /proc. The other goes below, in the
> per-process task directories.
>
> You then have either N or M thin
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> Jan Engelhardt writes:
>> On Apr 10 2007 17:47, Jan Engelhardt wrote:
>>> On Apr 8 2007 20:57, Oleg Nesterov wrote:
>
Anyway, re-parenting to swapper breaks pstree, it doesn't
show kernel threads. And if ->parent == /sbin/init, we can't
Jan Engelhardt writes:
On Apr 10 2007 17:47, Jan Engelhardt wrote:
On Apr 8 2007 20:57, Oleg Nesterov wrote:
Anyway, re-parenting to swapper breaks pstree, it doesn't
show kernel threads. And if ->parent == /sbin/init, we can't
remove us from ->children (unless we forbid sub-thread-of-init
ex
Robin Holt writes:
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
Robin Holt <[EMAIL PROTECTED]> writes:
I would say this is more a benefit than a problem. With a couple
of these systems we are testing, the number of kernel threads is
far greater than the number of user p
On Apr 10 2007 17:47, Jan Engelhardt wrote:
>On Apr 8 2007 20:57, Oleg Nesterov wrote:
>>
>>Anyway, re-parenting to swapper breaks pstree, it doesn't show kernel
>>threads. And if ->parent == /sbin/init, we can't remove us from ->children
>>(unless we forbid sub-thread-of-init exec). So the only s
On Apr 8 2007 20:57, Oleg Nesterov wrote:
>
>Anyway, re-parenting to swapper breaks pstree, it doesn't show kernel
>threads. And if ->parent == /sbin/init, we can't remove us from ->children
>(unless we forbid sub-thread-of-init exec). So the only safe change is
>set ->exit_state = -1.
Then we ha
On Mon, Apr 09, 2007 at 06:35:39PM -0600, Eric W. Biederman wrote:
> Robin Holt <[EMAIL PROTECTED]> writes:
>
> > OK. I just got the OK from management. The system we were booting was
> > for research only. We had NR_CPUS=num_online_cpus()=4096 which were
> > non-hyperthreaded. With no attache
Robin Holt <[EMAIL PROTECTED]> writes:
> OK. I just got the OK from management. The system we were booting was
> for research only. We had NR_CPUS=num_online_cpus()=4096 which were
> non-hyperthreaded. With no attached I/O and the tweak I originally
> posted plus one change Jack has already go
OK. I just got the OK from management. The system we were booting was
for research only. We had NR_CPUS=num_online_cpus()=4096 which were
non-hyperthreaded. With no attached I/O and the tweak I originally
posted plus one change Jack has already gotten accepted, the machine
booted in approx 12 m
Roland McGrath <[EMAIL PROTECTED]> writes:
> I concur with Eric's assessment. Adding new magic bits to the generic
> clone path seems like a poor way to cope with kernel threads. I think
> it's better if kernel thread setup gets less like normal user process
> setup. I also agree with Eric that
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
> Robin Holt <[EMAIL PROTECTED]> writes:
>
> > I would say this is more a benefit than a problem. With a couple of these
> > systems we are testing, the number of kernel threads is far greater than
> > the number of user processes
Robin Holt <[EMAIL PROTECTED]> writes:
> I would say this is more a benefit than a problem. With a couple of these
> systems we are testing, the number of kernel threads is far greater than
> the number of user processes and having pstree not normally show them, but
> maybe have an option we add
On Mon, Apr 09, 2007 at 01:06:43PM +0400, Oleg Nesterov wrote:
> On 04/08, Eric W. Biederman wrote:
> > There is a practical question how much we care about pstree being
> > confused (I assume it doesn't crash). If this is just a confusion
> > issue then I say go for it. PPID == 0 is a very legit
On 04/08, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > Perhaps it is better to add reparent_kthread() (next patch) to kthread()
> > and forget about CLONE_KERNEL_THREAD.
>
> Please.
OK, will do tomorrow.
> > Anyway, re-parenting to swapper breaks pstree, it does
I concur with Eric's assessment. Adding new magic bits to the generic
clone path seems like a poor way to cope with kernel threads. I think
it's better if kernel thread setup gets less like normal user process
setup. I also agree with Eric that PPID of 0 is a very natural way for
kernel threads
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/08, Eric W. Biederman wrote:
>
>> If we are going to have kernel only flags please use an additional
>> argument to do_fork and copy_process.
>
> Yes, we can do this. But we have a number of architectures which use
> sys_clone() to implement kernel
On 04/08, Eric W. Biederman wrote:
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > For review only.
> >
> > To implement for-in-kerenl-use-only CLONE_ flags, we need to filter out them
> > in sys_clone().
>
> Nack
>
> The current clone_flags field is for user space consumption and we
> have pr
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> For review only.
>
> To implement for-in-kerenl-use-only CLONE_ flags, we need to filter out them
> in sys_clone().
Nack
The current clone_flags field is for user space consumption and we
have proposed users for all or almost all of the remaining bits.
For review only.
To implement for-in-kerenl-use-only CLONE_ flags, we need to filter out them
in sys_clone().
These below
arch/sparc/
arch/sparc64/
arch/ia64/
arch/v850/
arch/xtensa/
are not changed, they use assembly to implement sys_clone().
Signed-off
23 matches
Mail list logo
