Oleg Nesterov <[EMAIL PROTECTED]> writes:
> Ah yes, we still need to export kthreadd_task... I just worried about subtle
> dependency this patch adds... This "kthreadd_task = find_task_by_pid" assumes
> that init/main.c:init() takes lock_kernel() before the first kthread_create().
There is a
On 04/11, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 04/11, Eric W. Biederman wrote:
> >>
> >> @@ -435,8 +436,12 @@ static void __init setup_command_line(char
> >> *command_line)
> >> static void noinline rest_init(void)
> >>__releases(kernel_lock)
> >>
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/11, Eric W. Biederman wrote:
>>
>> @@ -435,8 +436,12 @@ static void __init setup_command_line(char
>> *command_line)
>> static void noinline rest_init(void)
>> __releases(kernel_lock)
>> {
>> +int pid;
>> kernel_thread(init,
On Wednesday, 11 April 2007 16:36, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> > On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > > On 04/11, Gautham R Shenoy wrote:
> > > >
> > > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > > >
> > >
On 04/11, Eric W. Biederman wrote:
>
> @@ -435,8 +436,12 @@ static void __init setup_command_line(char *command_line)
> static void noinline rest_init(void)
> __releases(kernel_lock)
> {
> + int pid;
> kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
>
On Wed, 11 Apr 2007 12:27:59 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> + strcpy(tsk->comm, "kthreadd");
We have this dopey set_task_comm() thing which is there to avoid
races when userspace is looking at this task's name via /proc.
It obviously doesn't matter in this case, but I
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kthread infrastructure from
initializing until after work queues have been initialized.
We want the properties of tasks created with kthread_create to be as close
as possible
Andrew Morton <[EMAIL PROTECTED]> writes:
> argh. Your description freely confuddles the terms "kernel thread" and
> "kthread". Can we not do that? Henceforth the term "kernel thread" refers
> to something which was started with kernel_thread() and "kthread" refers to
> something which was
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/10, Eric W. Biederman wrote:
>>
>> +int kthreadd(void *unused)
>> +{
>> +/* Setup a clean context for our children to inherit. */
>> +kthreadd_setup();
>> +
>> +current->flags |= PF_NOFREEZE;
>> +
>> +for (;;) {
>> +
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/10, Eric W. Biederman wrote:
>>
>> static int kthread(void *_create)
>> {
>> struct kthread_create_info *create = _create;
>> int (*threadfn)(void *data);
>> void *data;
>> -sigset_t blocked;
>> int ret = -EINTR;
>>
>>
On 04/11, Gautham R Shenoy wrote:
> On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > On 04/11, Gautham R Shenoy wrote:
> > >
> > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > It should be calling try_to_freeze() somewhere anyway. We may
On Wednesday, 11 April 2007 15:31, Gautham R Shenoy wrote:
> On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > On 04/11, Gautham R Shenoy wrote:
> > >
> > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > It should be calling try_to_freeze()
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> >
> > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > >
> > > It should be calling try_to_freeze() somewhere anyway. We may need to
> > > freeze
> > > all tasks in some
On 04/10, Eric W. Biederman wrote:
>
> static int kthread(void *_create)
> {
> struct kthread_create_info *create = _create;
> int (*threadfn)(void *data);
> void *data;
> - sigset_t blocked;
> int ret = -EINTR;
>
> - kthread_exit_files();
> -
> - /* Copy
On 04/10, Eric W. Biederman wrote:
>
> +int kthreadd(void *unused)
> +{
> + /* Setup a clean context for our children to inherit. */
> + kthreadd_setup();
> +
> + current->flags |= PF_NOFREEZE;
> +
> + for (;;) {
> + wait_event(kthread_create_work,
> +
On 04/11, Gautham R Shenoy wrote:
>
> On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> >
> > It should be calling try_to_freeze() somewhere anyway. We may need to
> > freeze
> > all tasks in some cases.
>
> How about
> for (;;) {
> try_to_freeze();
>
> ?
Why?
>
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
>
> It should be calling try_to_freeze() somewhere anyway. We may need to freeze
> all tasks in some cases.
How about
for (;;) {
try_to_freeze();
?
This change allows us to make all the worker threads freezeable by
On Wednesday, 11 April 2007 09:03, Andrew Morton wrote:
> On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
> > Currently there is a circular reference between work queue initialization
> > and kthread initialization. This prevents the kernel thread
> >
On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Currently there is a circular reference between work queue initialization
> and kthread initialization. This prevents the kernel thread
> infrastructure from initializing until after work queues have been
>
On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure from initializing until after work queues have been
On Wednesday, 11 April 2007 09:03, Andrew Morton wrote:
On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
wrote:
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway. We may need to freeze
all tasks in some cases.
How about
for (;;) {
try_to_freeze();
?
This change allows us to make all the worker threads freezeable by
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway. We may need to
freeze
all tasks in some cases.
How about
for (;;) {
try_to_freeze();
?
Why?
This change allows
On 04/10, Eric W. Biederman wrote:
+int kthreadd(void *unused)
+{
+ /* Setup a clean context for our children to inherit. */
+ kthreadd_setup();
+
+ current-flags |= PF_NOFREEZE;
+
+ for (;;) {
+ wait_event(kthread_create_work,
+
On 04/10, Eric W. Biederman wrote:
static int kthread(void *_create)
{
struct kthread_create_info *create = _create;
int (*threadfn)(void *data);
void *data;
- sigset_t blocked;
int ret = -EINTR;
- kthread_exit_files();
-
- /* Copy data: it's on
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway. We may need to
freeze
all tasks in some cases.
How
On Wednesday, 11 April 2007 15:31, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway.
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway. We may need to
freeze
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/10, Eric W. Biederman wrote:
static int kthread(void *_create)
{
struct kthread_create_info *create = _create;
int (*threadfn)(void *data);
void *data;
-sigset_t blocked;
int ret = -EINTR;
-
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/10, Eric W. Biederman wrote:
+int kthreadd(void *unused)
+{
+/* Setup a clean context for our children to inherit. */
+kthreadd_setup();
+
+current-flags |= PF_NOFREEZE;
+
+for (;;) {
+
Andrew Morton [EMAIL PROTECTED] writes:
argh. Your description freely confuddles the terms kernel thread and
kthread. Can we not do that? Henceforth the term kernel thread refers
to something which was started with kernel_thread() and kthread refers to
something which was created by
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kthread infrastructure from
initializing until after work queues have been initialized.
We want the properties of tasks created with kthread_create to be as close
as possible
On Wed, 11 Apr 2007 12:27:59 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
+ strcpy(tsk-comm, kthreadd);
We have this dopey set_task_comm() thing which is there to avoid
races when userspace is looking at this task's name via /proc.
It obviously doesn't matter in this case, but I
On 04/11, Eric W. Biederman wrote:
@@ -435,8 +436,12 @@ static void __init setup_command_line(char *command_line)
static void noinline rest_init(void)
__releases(kernel_lock)
{
+ int pid;
kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
numa_default_policy();
On Wednesday, 11 April 2007 16:36, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/11, Eric W. Biederman wrote:
@@ -435,8 +436,12 @@ static void __init setup_command_line(char
*command_line)
static void noinline rest_init(void)
__releases(kernel_lock)
{
+int pid;
kernel_thread(init, NULL, CLONE_FS |
On 04/11, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/11, Eric W. Biederman wrote:
@@ -435,8 +436,12 @@ static void __init setup_command_line(char
*command_line)
static void noinline rest_init(void)
__releases(kernel_lock)
{
+ int pid;
Oleg Nesterov [EMAIL PROTECTED] writes:
Ah yes, we still need to export kthreadd_task... I just worried about subtle
dependency this patch adds... This kthreadd_task = find_task_by_pid assumes
that init/main.c:init() takes lock_kernel() before the first kthread_create().
There is a small
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure from initializing until after work queues have been
initialized.
For kernel threads we want something that is as close as possible to the
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure from initializing until after work queues have been
initialized.
For kernel threads we want something that is as close as possible to the
40 matches
Mail list logo
