Re: [gentoo-amd64] xmms-wma inoperable
> xmms loads the files, it can display wma header but when play is pressed > it speeds through the titles with no sound output. > I peeked around in the net and there seems to be some issue with the > libwma library... > Does any of you have a solution to this??? I am having the same trouble with aac files in xmms, to the point where xmms now segfaults. -- Rob Lesslie -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Hello, Le Lundi 06 Février 2006 19:50, Duncan a écrit : > Fragmentation doesn't tend to be as much of an issue on Linux, with "real" > filesystems, as on MSWormOS, particularly FAT/FAT32. I'm running all > reiserfs here, FWIW. It doesn't have a compaction tool (defrag, on > MSWormOS), but I've not noticed any issues as a result. Fragmentation seems to be a myth for anyone on Linux, and I was enclined to believe that myth until I started to use Gentoo. At first, a brand new gentoo system is fast, but after a few months and a dozen emerge -uDN world, things tend to slow down to a point that is barely acceptable. In fact, the first time I tought that maybe I installed too many things, and that my system was crippled with cruft. But then I had to repartition my hard drive, so I made a backup (tar zcvpf) of my different partitions, fdisk, mkfs, and tar zxvpf. The system was exactly the same as before, just the partition size had changed. But then emerge -S was much faster than before the operation, as well as common portage operations. Since then, I've tried to do the same on several servers, without the fdisk operation, just tar cp, mkfs, tar xp, and I've always noticed an appreciable speedup. The only explanation that comes from this experiment is fragmentation. And I think Gentoo is more sensible to fragmentation than binary distributions because it has to deal with many small files, often changing, during compilation and rsynchronisation. So the directories sensible to fragmentation are IMHO, /var/tmp and /usr/portage, and they are the ones to put on different partitions. Now, I don't have exact numbers to prove my sayings, but anyone can make the test themself, if they already have /var/tmp and/or /usr/portage on separate partitions. I didn't have time yet to sort out what kind of filesystem is more or less sensible to fragmentation, but from my experience, ext[23] is not a good candidate for /var/tmp or /usr/postage. Reiser3 has proven to fragment too, and one of the last system I installed was formated with XFS, which I will "defragment" in a few weeks. Hopefully I could then come with numbers. BTW, does someone know of a tools to show the fragmentation level of a *nix filesystem ? David -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Hello, I to have noticed a 'slowing' affect. Naturally I dismissed fragmentation. Is this 'normal' and fixable? On Wed, 2006-02-08 at 11:54 +0100, David Guerizec wrote: > Hello, > > Le Lundi 06 Février 2006 19:50, Duncan a écrit : > > Fragmentation doesn't tend to be as much of an issue on Linux, with "real" > > filesystems, as on MSWormOS, particularly FAT/FAT32. I'm running all > > reiserfs here, FWIW. It doesn't have a compaction tool (defrag, on > > MSWormOS), but I've not noticed any issues as a result. > > Fragmentation seems to be a myth for anyone on Linux, and I was enclined to > believe that myth until I started to use Gentoo. > > At first, a brand new gentoo system is fast, but after a few months and a > dozen emerge -uDN world, things tend to slow down to a point that is barely > acceptable. In fact, the first time I tought that maybe I installed too many > things, and that my system was crippled with cruft. > But then I had to repartition my hard drive, so I made a backup (tar zcvpf) > of > my different partitions, fdisk, mkfs, and tar zxvpf. > The system was exactly the same as before, just the partition size had > changed. > But then emerge -S was much faster than before the operation, as well as > common portage operations. > > Since then, I've tried to do the same on several servers, without the fdisk > operation, just tar cp, mkfs, tar xp, and I've always noticed an appreciable > speedup. > > The only explanation that comes from this experiment is fragmentation. > And I think Gentoo is more sensible to fragmentation than binary > distributions > because it has to deal with many small files, often changing, during > compilation and rsynchronisation. > > So the directories sensible to fragmentation are IMHO, /var/tmp > and /usr/portage, and they are the ones to put on different partitions. > > Now, I don't have exact numbers to prove my sayings, but anyone can make the > test themself, if they already have /var/tmp and/or /usr/portage on separate > partitions. > > I didn't have time yet to sort out what kind of filesystem is more or less > sensible to fragmentation, but from my experience, ext[23] is not a good > candidate for /var/tmp or /usr/postage. Reiser3 has proven to fragment too, > and one of the last system I installed was formated with XFS, which I will > "defragment" in a few weeks. Hopefully I could then come with numbers. > > BTW, does someone know of a tools to show the fragmentation level of a *nix > filesystem ? > > David > > > > -- Dr Gavin Seddon School of Pharmacy and Pharmaceutical Sciences University of Manchester Oxford Road, Manchester M13 9PL, U.K. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
According SGI, XFS is supposed to ship with a defrag tool (xfs_fsr) but it does not seem to be included with xfsprogs on gentoo. -- Rob Lesslie -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Rob Lesslie, mused, then expounded: > According SGI, XFS is supposed to ship with a defrag tool (xfs_fsr) > but it does not seem to be included with xfsprogs on gentoo. > -- > Rob Lesslie > It's part of - xfsdump. As shipped, IRIX includes a cron job that runs xfs_fsr once per week. But the typical IRIX customer tends to use the filesystem much more than most Linux users. Bob - -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
On 2/8/06, David Guerizec <[EMAIL PROTECTED]> wrote: > So the directories sensible to fragmentation are IMHO, /var/tmp > and /usr/portage, and they are the ones to put on different partitions. I tend to agree with you. They should also be no larger than necessary. My current partition setup is: /boot100M / 6G /tmp 2G /var 5G /usr/portage 1G /usr/portage/packages 6G (includes distfiles) /usr/src 2G /home 66G (the rest of the disk) My feeling is that if you partition sensibly, you don't need to worry much about fragmentation. > Now, I don't have exact numbers to prove my sayings, but anyone can make the > test themself, if they already have /var/tmp and/or /usr/portage on separate > partitions. _Many_ people have reported speedups from having portage on a small separate volume/partition. > I didn't have time yet to sort out what kind of filesystem is more or less > sensible to fragmentation, but from my experience, ext[23] is not a good > candidate for /var/tmp or /usr/postage. Reiser3 has proven to fragment too, > and one of the last system I installed was formated with XFS, which I will > "defragment" in a few weeks. Hopefully I could then come with numbers. XFS is probably the most resistant to fragmentation due to it's extents based format and delayed allocation feature. But in all of the tests I've done on my system, xfs was slower than ext3 for the tasks I care about (backup and restore performance). But there were some improvements in xfs in 2.6.16 that I have been meaning to try out. There is an excellent paper written by the ext3 authors on what they are working on. It gives a good basis for understanding the tradeoffs between xfs, ext3, and reiserfs and their different features: http://ext2.sourceforge.net/2005-ols/paper-html/index.html -Richard -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
On 2/8/06, Bob Sanders <[EMAIL PROTECTED]> wrote: > As shipped, IRIX includes a cron job that runs xfs_fsr once per week. But the > typical IRIX customer tends to use the filesystem much more than most Linux > users. IMO xfs_fsr is a little brain-damaged in it's operation (won't consolidate free space, requires enough space to fully copy a fragmented file, etc). It is probably not worth running if you have a sensible partition setup. -Richard -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Richard Fish, mused, then expounded: > > IMO xfs_fsr is a little brain-damaged in it's operation (won't > consolidate free space, requires enough space to fully copy a > fragmented file, etc). It is probably not worth running if you have a > sensible partition setup. > It was never designed to work like a WinXX defragger. The man page states exactly what it will do, and consolidating space is not part of it's design. >From the man page - fsr_xfs improves the organization of mounted filesystems. The reorganization algorithm operates on one file at a time, compacting or otherwise improving the layout of the file extents (contiguous blocks of file data). and - When invoked with no arguments fsr_xfs reorganizes all regular files in all mounted filesystems. fsr_xfs makes many cycles over /etc/mtab each time making a single pass over each XFS filesystem. Each pass goes through and selects files that have the largest number of extents. It attempts to defragment the top 10% of these files on each pass. and - fsr_xfs improves the layout of extents for each file by copying the entire file to a temporary location and then interchanging the data extents of the target and temporary files in an atomic manner. This method requires that enough free disk space be available to copy any given file and that the space be less fragmented then the original file. It also requires the owner of the file to have enough remaining filespace quota to do the copy on systems running quotas. fsr_xfs generates a warning message if space is not sufficient to improve the target file. Note - IRIX it's fsr_xfs and Linux it's xfs_fsr. Thus it may not, as you point out, perform the operations that you want it too. xfs_fsr/fsr_xfs was designed to deal with multi-gigabyte and terabyte files. Not to free up space in small partitions. Bob - -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
On 2/8/06, Bob Sanders <[EMAIL PROTECTED]> wrote: > > It was never designed to work like a WinXX defragger. The man page states > exactly what it will do, and consolidating space is not part of it's > design. Yes, I've read the man page, and I understood it. Also, I didn't mean to deride xfs or xfs_fsr/fsr_xfs, so please don't take it personally. It is the *only* filesystem that offers a online defrag tool for linux today, and that is a big bonus. My complaint is more of a wish list than anything else. But it isn't a big enough wish for me to spend time working on it myself! > xfs_fsr/fsr_xfs was designed to deal with multi-gigabyte and terabyte files. > Not > to free up space in small partitions. My comment about "not worth running" should have been qualified to small filesystems with small files (like root, ported, et al). But actually, it is with the handling of multi-gigabyte files that I find it lacking. My VMWare virtual disk images are 10-20G. So if I don't have at least 20G of free space on a filesystem, I cannot defragment those. Moreover, since xfs_fsr doesn't consolidate free space, it is probable that no improvements could be made to those files even if I have 50G free, since there are likely to be some files spread out over the disk if the filesystem has been in use for any length of time. -Richard -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Richard Fish, mused, then expounded: > > Also, I didn't mean to deride xfs or xfs_fsr/fsr_xfs, so please don't > take it personally. It's just a problem with perception. Say "defragger" and everyone thinks that Norton Utilites' disk utils have been cloned for Linux. I didn't take it personally, but didn't want others to assume that space compaction would be part of xfs_fsr. > It is the *only* filesystem that offers a online > defrag tool for linux today, and that is a big bonus. My complaint is > more of a wish list than anything else. But it isn't a big enough > wish for me to spend time working on it myself! > Well, it does also offer a fairly painless partition copy/restore, which actually works very well, if there is an extra drive around. > > But actually, it is with the handling of multi-gigabyte files that I > find it lacking. My VMWare virtual disk images are 10-20G. So if I > don't have at least 20G of free space on a filesystem, I cannot > defragment those. Moreover, since xfs_fsr doesn't consolidate free > space, it is probable that no improvements could be made to those > files even if I have 50G free, since there are likely to be some files > spread out over the disk if the filesystem has been in use for any > length of time. > True enough. Though the original customers that xfs_fsr was written for were running multi-terabyte arrays where a 20 GB file was a small single texture. Even those running HDTV editing on a 1P box were working with 300 GB of video (15 minutes). Thus they typically had the need for 3x the space during editing, but had plenty of free space for defragging the file. Thus the target audience were those with attached raid/jbod arrays. But again, I was just attempting to clarify vs. being offended. Apologies if it came across that way. Bob - -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Richard Fish posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 08 Feb 2006 08:40:11 -0700: > n 2/8/06, David Guerizec <[EMAIL PROTECTED]> wrote: >> So the directories sensible to fragmentation are IMHO, /var/tmp >> and /usr/portage, and they are the ones to put on different partitions. > > I tend to agree with you. They should also be no larger than > necessary. My current partition setup is: > > /boot100M > / 6G > /tmp 2G > /var 5G > /usr/portage 1G > /usr/portage/packages 6G (includes distfiles) > /usr/src 2G > /home 66G (the rest of the disk) > > My feeling is that if you partition sensibly, you don't need to worry > much about fragmentation. Much the same here, except that /var is on /, for reasons I explained elsewhere, but /var/log is a dedicated partition. Likewise, I have several partitions that hold data that would normally be part of /home, so /home itself is smaller, 10 gig or so. My big partition is the multi-media partition, with data that would ordinarily be on /home. $df FilesystemSize Used Avail Use% Mounted on /dev/md_d1p1 9.6G 1.6G 8.0G 17% / dev 2.0M 328K 1.7M 17% /dev /dev/md_d2p1 12G 7.6G 4.0G 66% /stryper /dev/md_d2p5 20G 159M 19G 1% /tmp /dev/mapper/vgraid6-home 10G 1.6G 8.5G 16% /h /dev/mapper/vgraid6-klbdo 512M 21M 492M 5% /klbdo /dev/mapper/vgraid6-local 1.0G 47M 978M 5% /l /dev/mapper/vgraid6-log 1.5G 434M 1.1G 29% /log /dev/mapper/vgraid6-mail 1.0G 65M 960M 7% /mail /dev/mapper/vgraid6-mm 60G 34G 27G 56% /mm /dev/mapper/vgraid6-news 12G 290M 12G 3% /news /dev/mapper/vgraid6-pkg 4.0G 1.6G 2.5G 40% /pkg shm50M 0 50M 0% /dev/shm svcdir2.0M 208K 1.8M 11% /var/lib/init.d Stryper (yes, I'm a fan of the band, it's my generic RAID-0 striped volume) is the one that contains my non-critical ccache, portage-tree, and usrsrc/kernel stuff. My fstab is /heavily/ commented, and includes all sorts of backup partition entries, plus my old single PATA disk entries, but here it is: $cat /e/fstab ### ### ### ### Common MntOpts: (a)sync,atime,auto(mount),dev,exec,_netdev,ro/rw,suid,user(s) ### ### defaults: auto,async,dev,exec,rw,suid,nouser ### ### user(s) note: user(s) may (un)mount, implies noexec,nosuid,nodev ### ### no- prefix: negates except (a)sync,_netdev,ro/rw,defaults ### ### ### ### ### ### ### Removable fs type note: Auto(detect) may be slow. Use comma type1,type2,type3. ### ### vfat type last, as it's not verified, and can overwrite others w/o checking.### ### udf (packet written optical) slow, but s/b b4 iso9660 if present. ### ### Thus, Floppy: ext2,,vfat. CD/DVD: udf,iso9660 or simply iso9660. ### ### ### ### ### ### ### partitions in order on disk (alpha for lvs) ### ### Dev/PartMntPnt TypeMntOpt D F ### ### ### ### ### ### for mount --bind, --rbind, and --move ### ### /old/dir/new/dirnonebind 0 0 ### ### ### ### raids -- sd[abcd] partitions (sdX3=autostripped swap, below, sdX4=ext.part) ### ### md0=sdX1=raid1, md_d1=sdX2=raid6, md_d2=sdX5=raid0, >sdX5=~100Gfree/drive ### ### ###
Re: [gentoo-amd64] Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite
Duncan wrote: >>Nice. Now let us know your CFLAGS, and what toolchain versions you're >>running :D > > > You probably didn't notice, as I had it commented out on the main index > page as I don't have the page created to actually list them yet, but if > you viewed source, you'd have seen I have a techspecs page link commented > out, that'll get that sort of info, when/if I actually get it created. > > However, since you asked, your answer, and a bit more, by way of > explanation... > > I should really create a page listing all the little Gentoo admin scripts > I've come up with and how I use them. I'm sure a few folks anyway would > likely find them useful. > > The idea behind most of them is to create shortcuts to having to type in > long emerge lines, with all sorts of arbitrary command line parameters. > The majority of these fall into two categories, ea* and ep*, short for > emerge --ask and emerge --pretend ... . Thus, I > have epworld and eaworld, the pretend and ask versions of emerge -NuDv > world, epsys and easys, the same for system, eplog , emerge > --pretend --log --verbose (package name to be added to the command line so > eplog gcc, for instance, to see the changes between my current and the new > version of gcc), eptree , to use the tree output, etc. Interesting. But why do you use scripts and not simple aliases? Every time you launch your script the HD performs a seek (which is very expensive in time), copies the script into memory and then forks a whole bash process to execute a one-liner. Using alias, which is a bash built-in, wouldn't fork a process and therefore be much faster. (see man alias for examples) > One thing I've found is that I'll often epworld or eptreeworld, then > emerge the individual packages, rather than use eaworld to do it. That > way, I can do them in the order I want or do several at a time if I want > to make use of both CPUs. Because I always use --deep, as I want to keep > my dependencies updated as well, I'm very often merging specific > dependencies. There's a small problem with that, however --oneshot, which > I'll always want to use with dependencies to help keep my world file > uncluttered, has no short form, but I use it as the default! OTOH, the man emerge: --oneshot (-1) IIRC --oneshot has a short form since 2.0.52 was released. > normal portage mode of adding stuff listed on the command line to the > world file, I don't want very often, as most of the time I'm simply > updating what I have, so it's all in the world file if it needs to be > there already anyway. Not a problem! All my regular ea* scriptlets use > --oneshot, so it /is/ my default. If I *AM* merging something new that I > want added to my world file, I have another family of ea* scriptlets that > do that -- all ending in "2", as in, "NOT --oneshot". Thus, I have a > family of ea*2 scriptlets. > > The regulars here already know one of my favorite portage features is > FEATURES=buildpkg, which I have set in make.conf. That of course gives me > a collection of binary versions of packages I've already emerged, so I > can quickly revert to an old version for testing something, if I want, > then remerge the new version once I've tested the old version to see if it > has the same bug I'm working on or not. To aid in this, I have a > collection of eppak and eapak scriptlets. Again, the portage default of > --usepackage (-k) doesn't fit my default needs, as if I'm using a binpkg, > I usually want to ONLY use a binpkg, NOT merge from source if the package > isn't available. That happens to be -K in short-form. However, it's my > default, so eapak invokes the -K version. I therefore have eapaK to > invoke the -k version if I don't really care whether it goes from binpkg > or source. > > Of course, there are various permutations of the above as well, so I have > eapak2 and eapaK2, as well as eapak and eapaK. For the ep* versions, of > course the --oneshot doesn't make a difference, so I only have eppak and > eppaK, no eppa?2 scriptlets. > > ... Deep breath... > > All that as a preliminary explanation to this: Along with the above, I > have a set of efetch functions, that invoke the -f form, so just do the > fetch, not the actual compile and merge, and esyn (there's already an > esync function in something or other I have merged so I just call it > esyn), which does emerge sync, then updates the esearch db, then > automatically fetches all the packages that an eaworld would want to > update, so they are ready for me to merge at my leisure. I'm a bit confused now. You use *functions* to do that? Or do you mean scripts? By the way: with alias you could name your custom "script" esync because it doesn't place a file on the harddisk. > Likewise, and the real reason for this whole explanation, I /had/ an > "einfo" scriptlet that simply ran "emerge info". This can be very handy > to run, if like me, you have several slotted versions of gcc merged, and > you sometime
Re: [gentoo-amd64] Re: Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite)
Duncan wrote: ### udf (packet written optical) slow, but s/b b4 iso9660 if present. ### Completely off-topic, but thank you for this info. I wondered how to access DVD-RAMs in Linux. Sebastian Redl -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] DRI on a Radeon 9550 with Xorg 7.0
Hi, I upgraded to Xorg 7.0 and everything seems to work very well except for 3D acceleration. When I run glxinfo I get: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) The only error that I see in the Xorg.0.log file is "No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 32" repeted several times. Except for that, DRM seems to initialize ok (I use the DRM modules included in the 2.6.15 kernel, the ones provided by the x11-drm package do not load correctly). Here are some log messages: andrei ~ # dmesg | grep -iE "agp|drm" Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected AGP bridge 0 agpgart: AGP aperture is 256M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 [drm] Initialized radeon 1.19.0 20050911 on minor 0: agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [drm] Loading R300 Microcode andrei ~ # grep -iE "agp|drm" /var/log/Xorg.0.log (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/lib64/xorg/modules/linux/libdrm.so (II) Module drm: vendor="X.Org Foundation" ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP), ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP), ATI Rage 128 Pro GL PA (PCI/AGP), ATI Rage 128 Pro GL PB (PCI/AGP), ATI Rage 128 Pro GL PC (PCI/AGP), ATI Rage 128 Pro GL PD (PCI), ATI Rage 128 Pro GL PE (PCI/AGP), ATI Rage 128 Pro GL PF (AGP), ATI Rage 128 Pro VR PG (PCI/AGP), ATI Rage 128 Pro VR PH (PCI/AGP), ATI Rage 128 Pro VR PI (PCI/AGP), ATI Rage 128 Pro VR PJ (PCI/AGP), ATI Rage 128 Pro VR PK (PCI/AGP), ATI Rage 128 Pro VR PL (PCI/AGP), ATI Rage 128 Pro VR PM (PCI/AGP), ATI Rage 128 Pro VR PN (PCI/AGP), ATI Rage 128 Pro VR PO (PCI/AGP), ATI Rage 128 Pro VR PP (PCI), ATI Rage 128 Pro VR PQ (PCI/AGP), ATI Rage 128 Pro VR PR (PCI), ATI Rage 128 Pro VR PS (PCI/AGP), ATI Rage 128 Pro VR PT (PCI/AGP), ATI Rage 128 Pro VR PU (PCI/AGP), ATI Rage 128 Pro VR PV (PCI/AGP), ATI Rage 128 Pro VR PW (PCI/AGP), ATI Rage 128 Pro VR PX (PCI/AGP), ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI), ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (PCI/AGP), ATI Rage 128 4X SF (PCI/AGP), ATI Rage 128 4X SG (PCI/AGP), ATI Rage 128 4X SH (PCI/AGP), ATI Rage 128 4X SK (PCI/AGP), ATI Rage 128 4X SL (PCI/AGP), ATI Rage 128 4X SM (AGP), ATI Rage 128 4X SN (PCI/AGP), ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?), ATI Rage 128 Pro ULTRA TU (AGP?) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon Mobility 9200 IGP 7835, ATI Radeon 9200PRO 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI FireGL RV360 AV (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon 9650, ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP),
[gentoo-amd64] Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite
Simon Stelling posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 08 Feb 2006 21:37:33 +0100: > Duncan wrote: >> I should really create a page listing all the little Gentoo admin scripts >> I've come up with and how I use them. I'm sure a few folks anyway would >> likely find them useful. >> >> The idea behind most of them is to create shortcuts to having to type in >> long emerge lines, with all sorts of arbitrary command line parameters. >> The majority of these fall into two categories, ea* and ep*, short for >> emerge --ask and emerge --pretend ... . Thus, I >> have epworld and eaworld, the pretend and ask versions of emerge -NuDv >> world, epsys and easys, the same for system, eplog , emerge >> --pretend --log --verbose (package name to be added to the command line so >> eplog gcc, for instance, to see the changes between my current and the new >> version of gcc), eptree , to use the tree output, etc. > > Interesting. But why do you use scripts and not simple aliases? Every time you > launch your script the HD performs a seek (which is very expensive in time), > copies the script into memory and then forks a whole bash process to execute a > one-liner. Using alias, which is a bash built-in, wouldn't fork a process and > therefore be much faster. My thinking, which is possibly incorrect (your input appreciated), is that file-based scripts get pulled into cache the first time they are executed, and will remain there (with a gig of memory) pretty much until I'm done doing my upgrades. At the same time, they are simply in cache, not something in bash's memory, so if the memory is needed, it will be reclaimed. As well, after I'm done and on to other tasks, the cached commands will eventually be replaced by other data, if need be. Aliases (and bash-functions) are held in memory. That's not as flexible as cache in terms of being knocked out of memory if the memory is needed by other things. Sure, that memory may be flushed to disk-based swap, but that's disk based the same as the actual script files I'm using, so reading it back into main memory if it's faulted out will take something comparable to the time it'd take to read in the script file again anyway. That's little gain, with the additional overhead and therefore loss of having to manage the temp-copy in swapped memory, if it comes to that. Actually, there are some details here that may affect things. I don't know enough about the following factors to be able to evaluate how they balance out, but the real reason I chose individual scripts is below. One, here anyway, tho not on most systems, I'm running four SATA disks in RAID. The swap is actually not on the RAID, as the kernel manages it like RAID on its own, provided all four swap areas are set to the same priority (they are), which means swap is running on the equivalent of four-way-striped RAID-0. Meanwhile, the scripts, as part of my main system, are on RAID-6 for redundancy, so with the same four disks backing the RAID-6 as the swap, I've only effectively two-way-striped storage there, the other two disk stripes being parity. Thus, retrieval from the 4-way-striped swap should in theory be more efficient than from the 2-way-striped regular storage. OTOH, the granularity of the stripe in either case, against the size of the one or two-line script, likely means that it'll be pulled from a single stripe (at the speed of reading from a single disk, tho there are parallelizing opportunities not available on a single disk). It's also likely that the swap will be more optimally managed for fast retrieval than the location on the regular filesystem is. Balanced against that we have the overhead of maintaining the swap tracking. That's assuming it would swap that out to the dedicated swap in the first place. I'm not familiar with Linux's VM, but given that the aliases and functions would be file-based in either case, it's possible it would simply drop the data from main memory, relying on the fact that that the data is clean file-backed data and could be read-in directly from the files again, if necessary, rather than bothering with actually creating a temporary copy of the /same/ data in swap, taking time to do so when it could just read it back in from the file. Another aspect is the effect of data vs metadata caching. Again, I'm not familiar with how Linux manages this, and indeed, it may differ between filesystems, but the idea is that if the file metadata is still cached, even if the file itself isn't, it's a single disk seek and read to read the data back in, as opposed to multiple seeks and reads, following the logical directory structure to fetch each directory table in the hierarchy until it reaches the entry that actually has the file location, before it can read the file itself, to read the file initially, or if the location metadata has been flushed as well. (Back several years ago on MSWormOS, one of the first things I always did after a reinstall was set the sy
Re: [gentoo-amd64] Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite
On Wed, 08 Feb 2006 21:37:33 +0100 Simon Stelling <[EMAIL PROTECTED]> wrote: > Duncan wrote: >> [ a book ;) ] > > You are referring a lot to the gcc manpage, but obviously you missed > this part: > >-fomit-frame-pointer >Don't keep the frame pointer in a register for functions > that don't need one. [...] > >Enabled at levels -O, -O2, -O3, -Os. >[...] On x86 this is not enabled since it interferes with debugging (info gcc isn't too clear on this, it's mentioned on the description of '-O') - is this different from amd64 (I'm still x86-only :/ )? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-amd64] Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite
On Wednesday 08 February 2006 16:41, Kevin F. Quinn (Gentoo) wrote: > On x86 this is not enabled since it interferes with debugging (info gcc > isn't too clear on this, it's mentioned on the description of '-O') - > is this different from amd64 (I'm still x86-only :/ )? x86_64 does not require frame pointers for debugging, so -fomit-frame-pointer is enabled with -O -- # # electronerd, the electronerdian from electronerdia # pgpc6E0Xq4S0W.pgp Description: PGP signature
