Re: Possible patch for limiting APs at startup
On 04-Mar-2003 Hiten Pandya wrote: John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: On 02-Mar-2003 Juli Mallett wrote: * De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Possible patch for limiting APs at startup ] Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. I think your use of cpus to refer to APs only is silly, and also that overriding mp_naps instead of using a real cpus value and using it as a bounds check akin to MAXCPU, is a bit of the wrong direction. As you know, the following is my patch, and it does not work, but I think, personally, the behaviour is saner, in theory at least :) You should set mp_maxcpus prior to the mp_naps test so it isn't left invalid in the common case. Also, this patch doesn't limit HT cpu's at all. I could have a 4 cpu system with HTT and maxcpus=2, and I will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps this is intentional? Yes. It was intentional, in the sense that we only want to limit the number of Application Processors, and not the HTT cores inside it, because that does not make much sense, IMHO. Do you think that patch will be committed, or does it need improving? (http://www.unixdaemons.com/~hiten/work/diffs/mp_machdep.c.patch) Juli's patch is much closer. Setting mp_naps directly is bogus at best. mp_naps would get reset by the mptable stuff anyways since SI_SUB_CPU is well after SI_SUB_TUNABLES. Ignoring HTT is fine. All I would really do is change juli's patch to set the max value before the if test so it is always valid. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible patch for limiting APs at startup
On 02-Mar-2003 Juli Mallett wrote:
* De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Possible patch for limiting APs at startup ]
Hello.
Just as the topic says, do you think this patch is good enough, or gets
even close to it? I have tested the patch, and it seems to do it's job
in the right way. Some might call it hackery, but it's better than
nothing I would suppose.
I think your use of cpus to refer to APs only is silly, and also that
overriding mp_naps instead of using a real cpus value and using it as
a bounds check akin to MAXCPU, is a bit of the wrong direction. As you
know, the following is my patch, and it does not work, but I think,
personally, the behaviour is saner, in theory at least :)
You should set mp_maxcpus prior to the mp_naps test so it isn't left
invalid in the common case. Also, this patch doesn't limit HT cpu's
at all. I could have a 4 cpu system with HTT and maxcpus=2, and I
will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps
this is intentional?
%%%
Index: mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.203
diff -d -c -r1.203 mp_machdep.c
*** mp_machdep.c 24 Feb 2003 14:36:03 - 1.203
--- mp_machdep.c 2 Mar 2003 00:22:58 -
***
*** 249,254
--- 249,259
/** XXX FIXME: what system files declare these??? */
extern struct region_descriptor r_gdt, r_idt;
+ int mp_maxcpus = 0; /* max CPUs; not in BSS so it can be hacked. */
+ TUNABLE_INT(machdep.smp_max_cpus, mp_maxcpus);
+ SYSCTL_INT(_machdep, OID_AUTO, smp_max_cpus, CTLFLAG_RD,
+mp_maxcpus, 1, Maximum number of CPUs to use.);
+
int bsp_apic_ready = 0; /* flags useability of BSP apic */
int mp_naps;/* # of Applications processors */
int mp_nbusses; /* # of busses */
***
*** 864,874
}
}
! /* qualify the numbers */
! if (mp_naps MAXCPU) {
printf(Warning: only using %d of %d available CPUs!\n,
! MAXCPU, mp_naps);
! mp_naps = MAXCPU;
}
/* See if we need to fixup HT logical CPUs. */
--- 869,881
}
}
! /* use the smallest number of requested CPUs or CPUs we support. */
! if ((mp_maxcpus 0 mp_naps mp_maxcpus) || mp_naps MAXCPU) {
! if (mp_maxcpus = 0)
! mp_maxcpus = MAXCPU;
printf(Warning: only using %d of %d available CPUs!\n,
! mp_maxcpus, mp_naps);
! mp_naps = mp_maxcpus;
}
/* See if we need to fixup HT logical CPUs. */
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Possible patch for limiting APs at startup
John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: On 02-Mar-2003 Juli Mallett wrote: * De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Possible patch for limiting APs at startup ] Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. I think your use of cpus to refer to APs only is silly, and also that overriding mp_naps instead of using a real cpus value and using it as a bounds check akin to MAXCPU, is a bit of the wrong direction. As you know, the following is my patch, and it does not work, but I think, personally, the behaviour is saner, in theory at least :) You should set mp_maxcpus prior to the mp_naps test so it isn't left invalid in the common case. Also, this patch doesn't limit HT cpu's at all. I could have a 4 cpu system with HTT and maxcpus=2, and I will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps this is intentional? Yes. It was intentional, in the sense that we only want to limit the number of Application Processors, and not the HTT cores inside it, because that does not make much sense, IMHO. Do you think that patch will be committed, or does it need improving? (http://www.unixdaemons.com/~hiten/work/diffs/mp_machdep.c.patch) Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Possible patch for limiting APs at startup
Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. Before: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 ... Launch AP CPUs etc ... After: boot-prompt set machdep.smp_cpus=0 boot-prompt boot -sv FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 Patch attached with mail. Cheers. P.S. One more question, there are some extern variables in the i386/include/smp.h header file, and I don't think they are used anywhere in an extern way... can comment on patch available at the following location: http://www.unixdaemons.com/~hiten/work/diffs/eremove.patch -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ Index: sys/i386/i386/mp_machdep.c === RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.203 diff -u -r1.203 mp_machdep.c --- sys/i386/i386/mp_machdep.c 24 Feb 2003 14:36:03 - 1.203 +++ sys/i386/i386/mp_machdep.c 2 Mar 2003 01:25:10 - @@ -278,6 +278,9 @@ int io_num_to_apic_id[NAPICID]; int apic_id_to_logical[NAPICID]; +TUNABLE_INT(machdep.smp_cpus, (int *)mp_naps); +SYSCTL_INT(_machdep, OID_AUTO, smp_cpus, CTLFLAG_RD, +mp_naps, 1, Number of Application processors in use.); /* AP uses this during bootstrap. Do not staticize. */ char *bootSTK;
Re: Possible patch for limiting APs at startup
* De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Possible patch for limiting APs at startup ]
Hello.
Just as the topic says, do you think this patch is good enough, or gets
even close to it? I have tested the patch, and it seems to do it's job
in the right way. Some might call it hackery, but it's better than
nothing I would suppose.
I think your use of cpus to refer to APs only is silly, and also that
overriding mp_naps instead of using a real cpus value and using it as
a bounds check akin to MAXCPU, is a bit of the wrong direction. As you
know, the following is my patch, and it does not work, but I think,
personally, the behaviour is saner, in theory at least :)
%%%
Index: mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.203
diff -d -c -r1.203 mp_machdep.c
*** mp_machdep.c24 Feb 2003 14:36:03 - 1.203
--- mp_machdep.c2 Mar 2003 00:22:58 -
***
*** 249,254
--- 249,259
/** XXX FIXME: what system files declare these??? */
extern struct region_descriptor r_gdt, r_idt;
+ int mp_maxcpus = 0; /* max CPUs; not in BSS so it can be hacked. */
+ TUNABLE_INT(machdep.smp_max_cpus, mp_maxcpus);
+ SYSCTL_INT(_machdep, OID_AUTO, smp_max_cpus, CTLFLAG_RD,
+ mp_maxcpus, 1, Maximum number of CPUs to use.);
+
int bsp_apic_ready = 0; /* flags useability of BSP apic */
int mp_naps;/* # of Applications processors */
int mp_nbusses; /* # of busses */
***
*** 864,874
}
}
! /* qualify the numbers */
! if (mp_naps MAXCPU) {
printf(Warning: only using %d of %d available CPUs!\n,
! MAXCPU, mp_naps);
! mp_naps = MAXCPU;
}
/* See if we need to fixup HT logical CPUs. */
--- 869,881
}
}
! /* use the smallest number of requested CPUs or CPUs we support. */
! if ((mp_maxcpus 0 mp_naps mp_maxcpus) || mp_naps MAXCPU) {
! if (mp_maxcpus = 0)
! mp_maxcpus = MAXCPU;
printf(Warning: only using %d of %d available CPUs!\n,
! mp_maxcpus, mp_naps);
! mp_naps = mp_maxcpus;
}
/* See if we need to fixup HT logical CPUs. */
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
