The attached patch makes anaconda stop neutering DRI/DRM (at least it should.) It does it by including the DRI userspace modules (from mesa) and the kernel DRM drivers.
Why do this?
To be more like the 'normal' installed system. Heck, if DRI's going to fail, the system's just going to blow up on the first boot anyway. Furthermore, there are cards/chips that do 2D accel via the 3D pipeline.
Plus, if we want to actually disable it in anaconda, we should do it explicitly, not by accident as a consequence of some files not being there.
Caveats: - listing the kernel drivers explicitly is a hack - this doesn't pull libGL onto the second stage. Assuming nothing dlopens() it, that shouldn't be a problem
Bill
Bill Nottingham wrote:
The attached patch makes anaconda stop neutering DRI/DRM (at least it should.) It does it by including the DRI userspace modules (from mesa) and the kernel DRM drivers.
Why do this?
To be more like the 'normal' installed system. Heck, if DRI's going to fail, the system's just going to blow up on the first boot anyway. Furthermore, there are cards/chips that do 2D accel via the 3D pipeline.
G'day Bill.
Isn't Anaconda big enough and slow enough yet? Last time I did an upgrade (as compared with an install) it ran for a good 12 hours.
If it's not essential for getting the install/upgrade done, _this_ user doesn't want it.
John Summerfield wrote:
Isn't Anaconda big enough and slow enough yet? Last time I did an upgrade (as compared with an install) it ran for a good 12 hours.
You really think anaconda itself chews up significant cpu time? If your upgrade took 12 hours I really doubt it was spending all that time crunching on anaconda. Disk or network IO is always the big slowdown.
Tracy R Reed wrote:
John Summerfield wrote:
Isn't Anaconda big enough and slow enough yet? Last time I did an upgrade (as compared with an install) it ran for a good 12 hours.
You really think anaconda itself chews up significant cpu time? If your upgrade took 12 hours I really doubt it was spending all that time crunching on anaconda. Disk or network IO is always the big slowdown.
No, not CPU. Anaconda and its associates seem to take a lot of RAM though, and that leads to excessive disk thrashing.
The computer concerned was doing a fine job of running FC3. After the upgrade, I felt obliged to add RAM.
John Summerfield (debian@herakles.homelinux.org) said:
To be more like the 'normal' installed system. Heck, if DRI's going to fail, the system's just going to blow up on the first boot anyway. Furthermore, there are cards/chips that do 2D accel via the 3D pipeline.
If it's not essential for getting the install/upgrade done, _this_ user doesn't want it.
Please read the last sentence again, then. Unless you want to force everything through vesa (which can make it slower...)
Bill
Bill Nottingham wrote:
John Summerfield (debian@herakles.homelinux.org) said:
To be more like the 'normal' installed system. Heck, if DRI's going to fail, the system's just going to blow up on the first boot anyway. Furthermore, there are cards/chips that do 2D accel via the 3D pipeline.
If it's not essential for getting the install/upgrade done, _this_ user doesn't want it.
Please read the last sentence again, then. Unless you want to force everything through vesa (which can make it slower...)
I commonly use vesa drivers. I don't do high-performance graphics work at all, and I never thought of Anaconda as being demanding of graphics. When it was being slow, I didn't think it was doing much graphics at all, and the progress bars seem to zip along at a satisfying rate when small packages are being installed.
I think Tracy's right, the bottleneck is disk and network I/o, and I'd suggest more of the former, taking into account swap activity when there's too little RAM.
Swap and/or rpm databases, see my very recent post "F9beta updates takes forever" on fedora-test.
Something over two hours applying about 500 Mbytes of updated rpms on a system sporting Intel(R) Core(TM)2 CPU and a new SATA drive.
On Mon, 2008-04-07 at 18:15 -0400, Bill Nottingham wrote:
The attached patch makes anaconda stop neutering DRI/DRM (at least it should.) It does it by including the DRI userspace modules (from mesa) and the kernel DRM drivers.
Why do this?
To be more like the 'normal' installed system. Heck, if DRI's going to fail, the system's just going to blow up on the first boot anyway. Furthermore, there are cards/chips that do 2D accel via the 3D pipeline.
So, I'm not fundamentally against doing this, but doing it right now is a little scary. ajax -- any thoughts from your end?
Plus, if we want to actually disable it in anaconda, we should do it explicitly, not by accident as a consequence of some files not being there.
Bleah, we used to, but as the X configuration stack has changed over time, we've lost those bits I suspect.
Caveats:
- listing the kernel drivers explicitly is a hack
I wonder if we'd be better with the (still a hack, but at least not a list of drivers) bit to do =drm and then map that to everything under drivers/char/drm
- this doesn't pull libGL onto the second stage. Assuming nothing dlopens() it, that shouldn't be a problem
The DRI modules static link libGL, so this might be a problem. Also, given that the dri modules are statically linked, it's going to be a not insubstantial space jump. From a quick test, mksquashfs /usr/lib/dri is 11 megs which is 10% of the size of stage2. Which isn't necessarily the end of the world, but it just continues to creep up various things. It might also make stage2 + kernel + initrd no longer fit on a 128 meg usb key
Jeremy
On Tue, 2008-04-08 at 00:02 -0400, Jeremy Katz wrote:
The DRI modules static link libGL, so this might be a problem. Also, given that the dri modules are statically linked, it's going to be a not insubstantial space jump. From a quick test, mksquashfs /usr/lib/dri is 11 megs which is 10% of the size of stage2. Which isn't necessarily the end of the world, but it just continues to creep up various things. It might also make stage2 + kernel + initrd no longer fit on a 128 meg usb key
I talked to ajax about that on the bus yesterday. He thought he had a couple possible ways of getting rid of the static link in each driver, and just use a shared library (that's private). That could save a significant amount of ondisk space, but not a change that any of us feel comfortable doing for F9 at this point.
Jesse Keating (jkeating@redhat.com) said:
The DRI modules static link libGL, so this might be a problem. Also, given that the dri modules are statically linked, it's going to be a not insubstantial space jump. From a quick test, mksquashfs /usr/lib/dri is 11 megs which is 10% of the size of stage2. Which isn't necessarily the end of the world, but it just continues to creep up various things. It might also make stage2 + kernel + initrd no longer fit on a 128 meg usb key
I talked to ajax about that on the bus yesterday. He thought he had a couple possible ways of getting rid of the static link in each driver, and just use a shared library (that's private). That could save a significant amount of ondisk space, but not a change that any of us feel comfortable doing for F9 at this point.
That's fine with me... this can be something to look at for F10.
Bill
On Tue, 2008-04-08 at 11:10 -0400, Bill Nottingham wrote:
Jesse Keating (jkeating@redhat.com) said:
The DRI modules static link libGL, so this might be a problem. Also, given that the dri modules are statically linked, it's going to be a not insubstantial space jump. From a quick test, mksquashfs /usr/lib/dri is 11 megs which is 10% of the size of stage2. Which isn't necessarily the end of the world, but it just continues to creep up various things. It might also make stage2 + kernel + initrd no longer fit on a 128 meg usb key
I talked to ajax about that on the bus yesterday. He thought he had a couple possible ways of getting rid of the static link in each driver, and just use a shared library (that's private). That could save a significant amount of ondisk space, but not a change that any of us feel comfortable doing for F9 at this point.
That's fine with me... this can be something to look at for F10.
And applied as is for now. Although it'd be nice to get to where we're not explicitly listing the modules before F10 (#446126)
Jeremy
anaconda-devel@lists.stg.fedoraproject.org