public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelianov <xemul@openvz.org>
To: Paul Menage <menage@google.com>
Cc: Kirill Korotaev <dev@sw.ru>, Andrew Morton <akpm@osdl.org>,
	ckrm-tech@lists.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	matthltc@us.ibm.com, hch@infradead.org,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	oleg@tv-sign.ru, devel@openvz.org, xemul@openvz.org
Subject: Re: [ckrm-tech] [PATCH 4/13] BC: context handling
Date: Thu, 23 Nov 2006 11:35:10 +0300	[thread overview]
Message-ID: <45655D3E.5020702@openvz.org> (raw)
In-Reply-To: <6599ad830611222348o1203357tea64fff91edca4f3@mail.gmail.com>

Paul Menage wrote:
> On 11/9/06, Kirill Korotaev <dev@sw.ru> wrote:
>> +
>> +int bc_task_move(int pid, struct beancounter *bc, int whole)
>> +{
> 
> ...
> 
>> +
>> +       down_write(&mm->mmap_sem);
>> +       err = stop_machine_run(do_set_bcid, &data, NR_CPUS);
>> +       up_write(&mm->mmap_sem);
> 
> Isn't this a little heavyweight for moving a task into/between
> beancounters?

It's a main reason we were against moving arbitrary task.

We need to track the situation when we change beancounter on
task that is currently handles an interrupt and thus set a
temporary BC as exec one. I see no other way that keeps pair
set_exec_bc()/get_exec_bc() lock-less.

The problem is even larger than I've described. set_exec_bc()
is used widely in OpenVZ beancounters to set temporary context
e.g. for skb handling. Thus we need some safe way to "catch"
the task in a "safe" place. In OpenVZ we solve this by moving
only current into beancounter. In this patch set we have to
move arbitrary task and thus - such complication.

I repeat - we can do this w/o stop_machine, but this would
require locking in set_exec_bc()/get_exec_bc() but it's too
bad. Moving tasks happens rarely but setting context is a
very common operation (e.g. in each interrupt).

We can do the following:

  if (tsk == current)
      /* fast way */
      tsk->exec_bc = bc;
  else
      /* slow way */
      stop_machine_run(...);

What do you think?

> Paul
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2006-11-23  8:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-09 16:49 BC: resource beancounters (v6) (with userpages reclamation + configfs) Kirill Korotaev
2006-11-09 16:53 ` [PATCH 1/13] BC: atomic_dec_and_lock_irqsave() helper Kirill Korotaev
2006-11-10 15:19   ` Cedric Le Goater
2006-11-10 16:46     ` Kirill Korotaev
2006-11-09 16:54 ` [PATCH 2/13] BC: Kconfig and Makefile Kirill Korotaev
2006-11-09 16:55 ` [PATCH 3/13] BC: beancounters core and API Kirill Korotaev
2006-11-09 16:57 ` [PATCH 4/13] BC: context handling Kirill Korotaev
2006-11-23  7:48   ` [ckrm-tech] " Paul Menage
2006-11-23  8:35     ` Pavel Emelianov [this message]
2006-11-23  8:53       ` Paul Menage
2006-11-23  9:20         ` Pavel Emelianov
2006-11-23  9:31           ` Paul Menage
2006-11-23  9:56             ` Pavel Emelianov
2006-11-23 10:18               ` Paul Menage
2006-11-23 10:45                 ` Pavel Emelianov
2006-11-24 10:10                 ` Pavel Emelianov
2006-11-25  0:09                   ` Paul Menage
2006-11-27  8:27                     ` Pavel Emelianov
2006-11-09 16:59 ` [PATCH 5/13] BC: configfs interface Kirill Korotaev
2006-11-09 17:00 ` [PATCH 6/13] BC: kmemsize accounting (core) Kirill Korotaev
2006-11-09 19:05   ` Paul Jackson
2006-11-10 22:46   ` Pekka Enberg
2006-11-13 12:13     ` Pavel Emelianov
2006-11-10 22:50   ` Pekka Enberg
2006-11-11  5:50   ` Pavel Machek
2006-11-09 17:01 ` [PATCH 7/13] BC: kmemsize accounting (hooks) Kirill Korotaev
2006-11-09 17:02 ` [PATCH 8/13] BC: privvmpages accounting (core) Kirill Korotaev
2006-11-09 17:04 ` [PATCH 9/13] BC: privvmpages accounting (hooks) Kirill Korotaev
2006-11-09 17:06 ` [PATCH 10/13] BC: physpages accounting (core) Kirill Korotaev
2006-11-09 17:08 ` [PATCH 11/13] BC: physpages accounting (hooks) Kirill Korotaev
2006-11-09 17:09 ` [PATCH 12/13] BC: numtasks accounting Kirill Korotaev
2006-11-09 17:09 ` [PATCH 13/13] BC: numfiles accounting Kirill Korotaev
2006-11-19 19:41 ` BC: resource beancounters (v6) (with userpages reclamation + configfs) Herbert Poetzl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45655D3E.5020702@openvz.org \
    --to=xemul@openvz.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@sw.ru \
    --cc=devel@openvz.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    --cc=oleg@tv-sign.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox