> On 6/12/2011 1:56 AM, Jason Hellenthal wrote:
>
> > Cutting modules out of the kernel in general does help speed up booting
> > but loading those same modules later in the boot process will just lead
> > you back to the same boot time.
>
> Loading modules via loader.conf is many times slower th
On Sun, Jun 12, 2011 at 11:11 PM, Eir Nym wrote:
> On 11 June 2011 22:17, Doug Barton wrote:
>> Howdy,
>>
>> Per discussion on -arch and the svn list about improving boot time and
>> stripping down the kernel to just that-which-cannot-be-modularized I created
>> the attached script to kldload mod
On 11 June 2011 22:17, Doug Barton wrote:
> Howdy,
>
> Per discussion on -arch and the svn list about improving boot time and
> stripping down the kernel to just that-which-cannot-be-modularized I created
> the attached script to kldload modules that don't need to be in loader.conf.
> It cut quite
TB --- 2011-06-13 02:42:42 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 02:42:42 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2011-06-13 02:42:42 - cleaning the object tree
TB --- 2011-06-13 02:42:48 - cvsupping the source tree
TB --- 2011-06-13 02:42:48 - /usr
TB --- 2011-06-13 02:42:35 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 02:42:35 - starting HEAD tinderbox run for mips/mips
TB --- 2011-06-13 02:42:35 - cleaning the object tree
TB --- 2011-06-13 02:42:43 - cvsupping the source tree
TB --- 2011-06-13 02:42:43 - /usr/bin/c
TB --- 2011-06-13 01:40:45 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 01:40:45 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-06-13 01:40:45 - cleaning the object tree
TB --- 2011-06-13 01:40:50 - cvsupping the source tree
TB --- 2011-06-13 01:40:50 - /usr/bin/c
TB --- 2011-06-13 00:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 00:50:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2011-06-13 00:50:00 - cleaning the object tree
TB --- 2011-06-13 00:50:09 - cvsupping the source tree
TB --- 2011-06-13 00:50:09 - /usr/bin/c
TB --- 2011-06-13 00:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 00:50:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2011-06-13 00:50:00 - cleaning the object tree
TB --- 2011-06-13 00:50:09 - cvsupping the source tree
TB --- 2011-06-13 00:50:09 - /usr/bin
TB --- 2011-06-13 00:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 00:50:00 - starting HEAD tinderbox run for i386/i386
TB --- 2011-06-13 00:50:00 - cleaning the object tree
TB --- 2011-06-13 00:50:09 - cvsupping the source tree
TB --- 2011-06-13 00:50:09 - /usr/bin/c
TB --- 2011-06-13 00:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-13 00:50:00 - starting HEAD tinderbox run for arm/arm
TB --- 2011-06-13 00:50:00 - cleaning the object tree
TB --- 2011-06-13 00:50:09 - cvsupping the source tree
TB --- 2011-06-13 00:50:09 - /usr/bin/csu
TB --- 2011-06-12 23:04:29 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 23:04:29 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2011-06-12 23:04:29 - cleaning the object tree
TB --- 2011-06-12 23:04:39 - cvsupping the source tree
TB --- 2011-06-12 23:04:39 - /usr
TB --- 2011-06-12 23:22:17 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 23:22:17 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2011-06-12 23:22:17 - cleaning the object tree
TB --- 2011-06-12 23:22:31 - cvsupping the source tree
TB --- 2011-06-12 23:22:31 - /usr
TB --- 2011-06-12 23:09:56 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 23:09:56 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2011-06-12 23:09:56 - cleaning the object tree
TB --- 2011-06-12 23:10:11 - cvsupping the source tree
TB --- 2011-06-12 23:10:11 - /u
TB --- 2011-06-12 23:04:08 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 23:04:08 - starting HEAD tinderbox run for mips/mips
TB --- 2011-06-12 23:04:08 - cleaning the object tree
TB --- 2011-06-12 23:04:15 - cvsupping the source tree
TB --- 2011-06-12 23:04:15 - /usr/bin/c
TB --- 2011-06-12 22:00:57 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 22:00:57 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-06-12 22:00:57 - cleaning the object tree
TB --- 2011-06-12 22:01:09 - cvsupping the source tree
TB --- 2011-06-12 22:01:09 - /usr/bin/c
TB --- 2011-06-12 21:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 21:10:01 - starting HEAD tinderbox run for i386/i386
TB --- 2011-06-12 21:10:01 - cleaning the object tree
TB --- 2011-06-12 21:10:28 - cvsupping the source tree
TB --- 2011-06-12 21:10:28 - /usr/bin/c
TB --- 2011-06-12 21:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 21:10:01 - starting HEAD tinderbox run for amd64/amd64
TB --- 2011-06-12 21:10:01 - cleaning the object tree
TB --- 2011-06-12 21:10:28 - cvsupping the source tree
TB --- 2011-06-12 21:10:28 - /usr/bin
TB --- 2011-06-12 21:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 21:10:01 - starting HEAD tinderbox run for i386/pc98
TB --- 2011-06-12 21:10:01 - cleaning the object tree
TB --- 2011-06-12 21:10:18 - cvsupping the source tree
TB --- 2011-06-12 21:10:18 - /usr/bin/c
> Yeah his message was around what I was thinking was wrong with loader or
> not neccesarily wrong but what it was limited to that was similiar to
> one of my previous messages stating contention, limitation, etc...
Sorry if my post was understood wrong. I did mean to say the culprit
was zfs,
TB --- 2011-06-12 21:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-12 21:10:01 - starting HEAD tinderbox run for arm/arm
TB --- 2011-06-12 21:10:01 - cleaning the object tree
TB --- 2011-06-12 21:10:16 - cvsupping the source tree
TB --- 2011-06-12 21:10:16 - /usr/bin/csu
On 6/12/2011 1:43 PM, Jason Hellenthal wrote:
Doug,
On Sun, Jun 12, 2011 at 12:46:58PM -0700, Doug Barton wrote:
On 6/12/2011 12:42 PM, Jason Hellenthal wrote:
Yes I agree. I was just stating that simply for the previous post
implying where ZFS was slower than UFS.
No, it wasn't. You compl
> Date: Sun, 12 Jun 2011 12:42:28 -0700
> From: Doug Barton
> Sender: owner-freebsd-curr...@freebsd.org
>
> On 6/12/2011 12:34 PM, Garrett Cooper wrote:
> > On Sun, Jun 12, 2011 at 12:24 PM, Gary Palmer wrote:
> >> On Sun, Jun 12, 2011 at 02:56:31PM -0400, Jason Hellenthal wrote:
> >>> So techni
On 6/12/2011 12:42 PM, Jason Hellenthal wrote:
Yes I agree. I was just stating that simply for the previous post
implying where ZFS was slower than UFS.
No, it wasn't. You completely fail to understand the problem. Stop
writing, and start reading. As in, read the threads on both -arch and
th
On 6/12/2011 12:34 PM, Garrett Cooper wrote:
On Sun, Jun 12, 2011 at 12:24 PM, Gary Palmer wrote:
On Sun, Jun 12, 2011 at 02:56:31PM -0400, Jason Hellenthal wrote:
So technically here a ZFS only install is lacking the speed in which
modules are loaded. I would prefer to find out why and fix th
On Sun, Jun 12, 2011 at 12:24 PM, Gary Palmer wrote:
> On Sun, Jun 12, 2011 at 02:56:31PM -0400, Jason Hellenthal wrote:
>> So technically here a ZFS only install is lacking the speed in which
>> modules are loaded. I would prefer to find out why and fix that before
>> we go about adding new funct
On 6/12/2011 12:16 PM, Jason Hellenthal wrote:
Doug,
On Sun, Jun 12, 2011 at 12:00:56PM -0700, Doug Barton wrote:
Absolutely not. That would not fit into the way we do things at all, and
would essentially require /etc/rc to do the processing, which is a huge
step in the wrong direction.
Ok
On Sun, Jun 12, 2011 at 02:56:31PM -0400, Jason Hellenthal wrote:
> So technically here a ZFS only install is lacking the speed in which
> modules are loaded. I would prefer to find out why and fix that before
> we go about adding new functionality to rcNG.
As I believe Doug has already said, its
On 6/12/2011 12:05 PM, Jason Hellenthal wrote:
Any opposition for keeping the syntax of loader.conf ?
nullfs_load="YES"
Yes, see my other message on this point.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experien
On 6/12/2011 11:56 AM, Jason Hellenthal wrote:
So technically here a ZFS only install is lacking the speed in which
modules are loaded.
It has nothing to do with zfs. It has to do with how the kernel and
modules are loaded at boot time, vs. after the disks are up. Please read
the threads on
On 6/12/2011 1:56 AM, Jason Hellenthal wrote:
Cutting modules out of the kernel in general does help speed up booting
but loading those same modules later in the boot process will just lead
you back to the same boot time.
Loading modules via loader.conf is many times slower than doing it from
I use some numerical code utilizing the SIMD units of modern X86
architectures. Code compiles well using gcc/gcc46,
but clang does not know about the __builtin_ia32_x() statements. How
to treat those in clang and how to make
C code compiling with clang utilizing those __builtin_ia32 statemen
Al 12/06/11 10:56, En/na Jason Hellenthal ha escrit:
>
> umass for one I could see how it would speed up your boot since you
> would not have to probe for USB devices to possibly mount root from but
> not a big show stopper for those who don't need that so this would come
> in handy in that case bu
If kldload could work in parallel,
this https://github.com/buganini/brackets may help.
--Buganini
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-un
33 matches
Mail list logo
