On 2008/2/25, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Feb 2008 14:12:47 +0100 "J.C. Pizarro" <[EMAIL PROTECTED]> wrote:
>
> > It's statistic, yes, but it's a very important parameter for the
> CPU-scheduler.
> > The CPU-sched
2008/2/25, Ady Wicaksono <[EMAIL PROTECTED]>:
> I have 8 Gbytes RAM, but why I can allocate 2.8 Gbytes RAM for a single
> process?
> How to patch kernel so I have more than 2.8 Gbytes limitation?
>
> Kernel:
> ---
> Linux xxx.com 2.6.9-023stab046.2-enterprise #1 SMP Mon
Good morning :)
On 2008/2/24, Rik van Riel <[EMAIL PROTECTED]> wrote:
> OK, one last reply on the (overly optimistic?) assumption that you are not a
> troll.
> > +++ linux-2.6_git-20080224/include/linux/sched.h2008-02-24
> > 04:50:18.0 +0100
> > @@ -1007,6 +1007,12 @@
> >
On 2008/2/24, Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Feb 2008 04:08:38 +0100
> "J.C. Pizarro" <[EMAIL PROTECTED]> wrote:
>
> > We will need 64 bit counters of the slow context switches,
> > one counter for each new created task (e.g. u
Hello,
We will need 64 bit counters of the slow context switches,
one counter for each new created task (e.g. u64 ctxt_switch_counts;)
We will only need them during the lifetime of the tasks.
To increment by +1 the task's 64 bit counter (it's fast)
each one slow context switch.
*kernel/sche
The google's gmail made a crap my last message that it did wrap
my message of X lines to the crap of (X+o) lines misconfiguring
my original lines of the message.
I don't see the motives of Google crapping my original lines
of the messages that i had sended.
--
To unsubscribe from this list
On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 02:36:59PM +0100, J.C. Pizarro wrote:
> > On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote:
> > >
>
> > > It shouldn't matter how aggressively the rep
On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 02:08:35PM +0100, J.C. Pizarro wrote:
> >
> > But if the repos are aggressively repacked then the bit to bit differences
> > are not ~2 MiB.
>
>
> It shouldn't matter how
On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 03:47:07AM +0100, J.C. Pizarro wrote:
> >
> > Yesterday, i had git cloned git://foo.com/bar.git ( 777 MiB )
> > Today, i've git cloned git://foo.com/bar.git ( 779 MiB )
>
On 2008/2/23, Al Viro <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote:
> > Al Viro <[EMAIL PROTECTED]> writes:
> >
> > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
> > >
> > >> >do you tend to clone the entire repository repeated
2008/2/23, Chase Venters <[EMAIL PROTECTED]> wrote:
>
> ... blablabla
>
> My question is: If you're working on multiple things at once, do you tend to
> clone the entire repository repeatedly into a series of separate working
> directories and do your work there, then pull that work (possibly co
On 2008/2/22, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> For
> comprension, unlocking
> some lockers of the task_migrators and inmediately switching CPU to
> migrators is similar to quick awakening of migr
In kernel/sched.c appears:
static void sched_migrate_task(struct task_struct *p, int dest_cpu)
{
struct migration_req req;
unsigned long flags;
struct rq *rq;
rq = task_rq_lock(p, &flags);
if (!cpu_isset(dest_cpu, p->cpus_allowed)
|| unlikely(cp
13 matches
Mail list logo
