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-scheduler will
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-scheduler will know the number of context switches of each task
before
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
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 Dec 10
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 @@
> >
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 @@
struct
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.
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.
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
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 reposito
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 aggr
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 )
> &g
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 )
Both repos are different binaries , and i
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 aggressively the repositories are packed or what
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 repositories are packed or what
the binary differences are between
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
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.
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. u64 ctxt_switch_counts;)
Please send a patch ...
diff
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
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
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, );
if (!cpu_isset(dest_cpu, p->cpus_allowed)
||
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)
||
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 migration_thread.
I'm sorry
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
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 repeatedly into a series
26 matches
Mail list logo
