Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-24 Thread Dmitry Morozovsky
On Tue, 24 Feb 2004, Tony Frank wrote:

[snip]

TF   : If True, for optimized code across all machines, the code should
TF   : just be built on each machine, right?
TF   That would give slightly better performance.  However, it can be more
TF   pain than it is worth if the number of machine types is high.
TF  Consuming considerably more time and disk space, a shell script to
TF  alter make.conf and rename /usr/obj between the build for each machine
TF  is doable, though pro'lly not worth it. The install at each each box
TF  would just have to mount it's corresponding /usr/obj tree.
TF
TF Just need to set __MAKE_CONF and MAKEOBJDIRPREFIX before running the build.

Unfortunately not, as some utilities (from phase III) will be linked against
existing system libraries. Or, you should follow the process like 'make
release': build world with lower CPU optimization, intall it to the sandbox,
chroot to it and build world again. This was explained by ru@ some months ago
[1,2]

[1]: http://www.geocrawler.com/archives/3/152/2002/5/0/8811539/
[2]:
http://groups.google.com/groups?hl=rulr=ie=UTF-8inlang=ruthreadm=fa.f0qca6v.f7g49v%40ifi.uio.nornum=4prev=/groups%3Fq%3Dfreebsd%2Bruslan%2Bermilov%2BCPUTYPE%2Bworld%2Bproblems%2Bwhen%2Brunning%2Bmake%26hl%3Dru%26lr%3D%26ie%3DUTF-8%26inlang%3Dru%26selm%3Dfa.f0qca6v.f7g49v%2540ifi.uio.no%26rnum%3D4

Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-23 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
D J Hawkey Jr [EMAIL PROTECTED] writes:
: True or False: Setting CPUTYPE to the lowest target CPU (p2) in
: a build machine's make.conf will cripple the performance of target
: machines with higher CPUs (p3, p4, i586, i686, etc.).

False.  It might have a minor impact on performance, but not a major
one.  At least in my experience.  Minor here means  10% for something
like the world stone.  Cripple to me implies  25%.

: If True, for optimized code across all machines, the code should
: just be built on each machine, right?

That would give slightly better performance.  However, it can be more
pain than it is worth if the number of machine types is high.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-23 Thread D J Hawkey Jr
On Feb 23, at 09:12 AM, M. Warner Losh wrote:
 
 In message: [EMAIL PROTECTED]
 D J Hawkey Jr [EMAIL PROTECTED] writes:
 : True or False: Setting CPUTYPE to the lowest target CPU (p2) in
 : a build machine's make.conf will cripple the performance of target
 : machines with higher CPUs (p3, p4, i586, i686, etc.).
 
 False.  It might have a minor impact on performance, but not a major
 one.  At least in my experience.  Minor here means  10% for something
 like the world stone.  Cripple to me implies  25%.

OK, thanks. Just to satisfy my anal-retentive side, would that ~10%
degradation be a higher level of performance on a PIII (or higher)
with no CPUTYPE specified at all, given the same *FLAGS?

 : If True, for optimized code across all machines, the code should
 : just be built on each machine, right?
 
 That would give slightly better performance.  However, it can be more
 pain than it is worth if the number of machine types is high.

Consuming considerably more time and disk space, a shell script to
alter make.conf and rename /usr/obj between the build for each machine
is doable, though pro'lly not worth it. The install at each each box
would just have to mount it's corresponding /usr/obj tree.

Thanks, Warner,
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-23 Thread Tony Frank
Hi,

On Mon, Feb 23, 2004 at 10:46:07AM -0600, D J Hawkey Jr wrote:
 On Feb 23, at 09:12 AM, M. Warner Losh wrote:
  
  In message: [EMAIL PROTECTED]
  D J Hawkey Jr [EMAIL PROTECTED] writes:
  : True or False: Setting CPUTYPE to the lowest target CPU (p2) in
  : a build machine's make.conf will cripple the performance of target
  : machines with higher CPUs (p3, p4, i586, i686, etc.).
  
  False.  It might have a minor impact on performance, but not a major
  one.  At least in my experience.  Minor here means  10% for something
  like the world stone.  Cripple to me implies  25%.
 
 OK, thanks. Just to satisfy my anal-retentive side, would that ~10%
 degradation be a higher level of performance on a PIII (or higher)
 with no CPUTYPE specified at all, given the same *FLAGS?

Perhaps the easiest option is to actually try it and see what the results
are?

  : If True, for optimized code across all machines, the code should
  : just be built on each machine, right?
  That would give slightly better performance.  However, it can be more
  pain than it is worth if the number of machine types is high.
 Consuming considerably more time and disk space, a shell script to
 alter make.conf and rename /usr/obj between the build for each machine
 is doable, though pro'lly not worth it. The install at each each box
 would just have to mount it's corresponding /usr/obj tree.

Just need to set __MAKE_CONF and MAKEOBJDIRPREFIX before running the build.

Regards,

Tony
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-22 Thread Tony Frank
Hi,

On Sat, Feb 21, 2004 at 11:23:28AM -0600, D J Hawkey Jr wrote:
 On Feb 21, at 05:56 PM, Gabriel Ambuehl wrote:
  
  DJHJ Second, two machines are of the same architecture, but they have different
  DJHJ CPUs: One is an Intel PIII, but the other is a PII. Will the world built
  DJHJ on a PIII be correct for a PII? Similarly, will the kernel for the PII
  DJHJ built on a PIII be correct for the PII, given the different variables and
  DJHJ settings in the two kernel configuration files?
  
  Just make sure you build for 686. If that doesn't work, make it 586 (I
  think the PI qualifies as 686 but I'm not entirely sure). I think the extensions 
  such as
  SSE etc are detected dynamically and shouldn't cause any problem.
  In all my years of messing with builds, I never run into this problem,
  so I guess it's pretty safe.
 Yes, both [my] machines define I686_CPU.
 
 Dynamically, as in at runtime? I think you're right, but I don't
 know for certain, either. This is exactly what I'm wondering about;
 the PII has only MMX, for instance, while the PIII has SSE and MMX2.
 
 I assume the world's codebase is CPU-agnostic within an architecture,
 but I really don't want to assume this; I'd rather know this.

I have PII, Celeron, PIII and P4 in my environment.
All these use I686_CPU in my kernel configs (I got rid of the other I[345]_CPU types.

In /etc/make.conf I include CPUTYPE=p2 as the lowest common denominator if 
including a CPUTYPE flag.
The resulting world  kernel run fine on all the systems.

The higher flags p3 and p4 still just use -march=pentiumpro, however for SSE you
will need p3 or p4 as MACHINE_CPU does not include SSE for p2 level.
Check out /usr/share/mk/bsd.cpu.mk for specifics.

  DJHJ /etc/defaults/make.conf doesn't mention KERNCONF; /usr/src/Makefile.inc1
  DJHJ does. Since /usr/share/mk/sys.mk sucks in /etc/make.conf, that should
  DJHJ propogate KERNCONF to /usr/src/Makefile, right?
  You can also
  just supply it on the command line when doing your make runs.
 Yes, but this means individual commands for each machine's kernel, as
 opposed to one command for all machines (think issue command and go to
 bed, or even an `at` command). Are you stating definitively that what
 I saw in the makefile chain isn't what is really there?

To your original question, yes.
Just add a KERNCONF= line to /etc/make.conf.
First entry should be the local machine kernel (to install) and
any subsequent entries will also be built during 'make buildkernel'
eg:
KERNCONF=   MARVIN RAIDER RAIDERI GENERIC

make buildkernel builds all four.
make installkernel installs MARVIN.

Good luck,

Tony

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-22 Thread D J Hawkey Jr
OK, I've cross-posted this message to -hackers, to see if we can get
some sort of definitive [to me] answer. Please forgive if it's considered
bad form.

-hackers: There is a thread in -questions in response to my query as
to building the world and kernels for a variety of Intel CPUs on one
machine. For brevity's sake, I won't reproduce the entire thread here.

OK, I guess my question boils down to these, then:

True or False: Setting CPUTYPE to the lowest target CPU (p2) in
a build machine's make.conf will cripple the performance of target
machines with higher CPUs (p3, p4, i586, i686, etc.).

If True, for optimized code across all machines, the code should
just be built on each machine, right?

Thanks,
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-21 Thread D J Hawkey Jr
Hi all.

I recently acquired a laptop whose world and kernel I'd like to have
built by a different machine on my LAN. Chapter 21.5 of the current
Handbook lays things out pretty well, but I do have a couple of questions
before proceeding.

The Handbook states: Finally[,] make sure that /etc/make.conf on all
the machines in the build set agrees with the build machine. That means
that the build machine must build all the parts of the base system that
any machine in the build set is going to install. Also, each build machine
should have its kernel name set with KERNCONF in /etc/make.conf, and the
build machine should list them all in KERNCONF, listing its own kernel
first. The build machine must have the kernel configuration files for each
machine in /usr/src/sys/arch/conf if it is going to build their kernels.

So, two machines use the same world, except that a laptop doesn't want
profiled libraries or games. Since the install is separate from the build,
the build machine's make.conf must _not_ define NOPROFILE nor NOGAMES,
but the laptop's make.conf _must_ define NOPROFILE and NOGAMES, such that
both are present when `make installworld` is run on the machine that wants
them, but they won't be installed when `make installworld` is run on the
laptop, right?

Second, two machines are of the same architecture, but they have different
CPUs: One is an Intel PIII, but the other is a PII. Will the world built
on a PIII be correct for a PII? Similarly, will the kernel for the PII
built on a PIII be correct for the PII, given the different variables and
settings in the two kernel configuration files?

Finally, after briefly following the makefile chain, it looks as though
what is written for -CURRENT is backward-compatible to 4.5-RELEASE?
/etc/defaults/make.conf doesn't mention KERNCONF; /usr/src/Makefile.inc1
does. Since /usr/share/mk/sys.mk sucks in /etc/make.conf, that should
propogate KERNCONF to /usr/src/Makefile, right?

Thanks,
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-21 Thread Gabriel Ambuehl
Hi D J Hawkey Jr,
you wrote.
DJHJ So, two machines use the same world, except that a laptop doesn't want
DJHJ profiled libraries or games. Since the install is separate from the build,
DJHJ the build machine's make.conf must _not_ define NOPROFILE nor NOGAMES,

If that machine itself wants those, yes. If you don't care for them (I
could never be bothered about either one), you don't need to build them, obviously.

DJHJ but the laptop's make.conf _must_ define NOPROFILE and NOGAMES, such that
DJHJ both are present when `make installworld` is run on the machine that wants
DJHJ them, but they won't be installed when `make installworld` is run on the
DJHJ laptop, right?

That should work, building more than you're going to install should be
ok, the other way round obviously won't work.

DJHJ Second, two machines are of the same architecture, but they have different
DJHJ CPUs: One is an Intel PIII, but the other is a PII. Will the world built
DJHJ on a PIII be correct for a PII? Similarly, will the kernel for the PII
DJHJ built on a PIII be correct for the PII, given the different variables and
DJHJ settings in the two kernel configuration files?

Just make sure you build for 686. If that doesn't work, make it 586 (I
think the PI qualifies as 686 but I'm not entirely sure). I think the extensions such 
as
SSE etc are detected dynamically and shouldn't cause any problem.
In all my years of messing with builds, I never run into this problem,
so I guess it's pretty safe.

DJHJ Finally, after briefly following the makefile chain, it looks as though
DJHJ what is written for -CURRENT is backward-compatible to 4.5-RELEASE?

I don't think it is. 4.5 is OLD. You might not even find 4.9 to be
backwards compatible to 4.5, much less CURRENT.

DJHJ /etc/defaults/make.conf doesn't mention KERNCONF; /usr/src/Makefile.inc1
DJHJ does. Since /usr/share/mk/sys.mk sucks in /etc/make.conf, that should
DJHJ propogate KERNCONF to /usr/src/Makefile, right?

I suggest you go for 4.9 anyhow. Then KERNCONF is ok. You can also
just supply it on the command line when doing your make runs.

Regards,
Gabriel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Clarification needed on Handbook: Tracking for Multiple Machines

2004-02-21 Thread D J Hawkey Jr
On Feb 21, at 05:56 PM, Gabriel Ambuehl wrote:
 
 DJHJ Second, two machines are of the same architecture, but they have different
 DJHJ CPUs: One is an Intel PIII, but the other is a PII. Will the world built
 DJHJ on a PIII be correct for a PII? Similarly, will the kernel for the PII
 DJHJ built on a PIII be correct for the PII, given the different variables and
 DJHJ settings in the two kernel configuration files?
 
 Just make sure you build for 686. If that doesn't work, make it 586 (I
 think the PI qualifies as 686 but I'm not entirely sure). I think the extensions 
 such as
 SSE etc are detected dynamically and shouldn't cause any problem.
 In all my years of messing with builds, I never run into this problem,
 so I guess it's pretty safe.

Yes, both [my] machines define I686_CPU.

Dynamically, as in at runtime? I think you're right, but I don't
know for certain, either. This is exactly what I'm wondering about;
the PII has only MMX, for instance, while the PIII has SSE and MMX2.

I assume the world's codebase is CPU-agnostic within an architecture,
but I really don't want to assume this; I'd rather know this.

 DJHJ Finally, after briefly following the makefile chain, it looks as though
 DJHJ what is written for -CURRENT is backward-compatible to 4.5-RELEASE?
 
 I don't think it is. 4.5 is OLD. You might not even find 4.9 to be
 backwards compatible to 4.5, much less CURRENT.

Yes, 4.5-REL is old, but I have too much vested in my 4.5-REL systems
to jump anytime soon. I have been maintaining my 4.5-REL systems WRT
post-4.5 security updates (right up to SA-04:02), and for what these
machines are and what they do, 4.5-REL is perfectly suitable.

 DJHJ /etc/defaults/make.conf doesn't mention KERNCONF; /usr/src/Makefile.inc1
 DJHJ does. Since /usr/share/mk/sys.mk sucks in /etc/make.conf, that should
 DJHJ propogate KERNCONF to /usr/src/Makefile, right?
 
 You can also
 just supply it on the command line when doing your make runs.

Yes, but this means individual commands for each machine's kernel, as
opposed to one command for all machines (think issue command and go to
bed, or even an `at` command). Are you stating definitively that what
I saw in the makefile chain isn't what is really there?

Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]