[gentoo-amd64] [OT] AGPART

[gentoo-amd64] [OT] AGPART

[Daniel Iliev]

Hi, guys

I have an NForce based motherboard with an integrated
[ surprise! ] :) NVidia PCI-X videocard. So, I don't need the agpart
driver for my kernel, right? The problem is that I can't switch it off:


> Linux Kernel v2.6.20-gentoo-r7 Configuration
>	Device Drivers
>		Character devices
>			 --- /dev/agpgart (AGP Support)


The help says:

>Selected by: IOMMU && PCI || FB_I810 && FB && EXPERIMENTAL && PCI &&
>X86_32 || FB_INTEL && FB && EXPERIMENTAL && PCI && X86


My questions:
- Is it normal?
- Should I disable it (how)? 


-- 
Best regards,
Daniel

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] AGPART

[Jeffrey Gardner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Iliev wrote:
> Hi, guys
> 
> I have an NForce based motherboard with an integrated
> [ surprise! ] :) NVidia PCI-X videocard. So, I don't need the agpart
> driver for my kernel, right? The problem is that I can't switch it off:
> 
> 
>> Linux Kernel v2.6.20-gentoo-r7 Configuration
>> 	Device Drivers
>> 		Character devices
>> 			 --- /dev/agpgart (AGP Support)
> 
> 
> The help says:
> 
>> Selected by: IOMMU && PCI || FB_I810 && FB && EXPERIMENTAL && PCI &&
>> X86_32 || FB_INTEL && FB && EXPERIMENTAL && PCI && X86
> 
> 
> My questions:
> - Is it normal?
> - Should I disable it (how)? 

General setup
[*] Configure standard kernel features (for small systems)  --->
[*]   Enable 16-bit UID system calls

                                     [*]   Sysctl syscall support


   [*]   Load all symbols for debugging/ksymoops

                                        [ ]     Do an extra kallsyms
pass

           [*]   Support for hot-pluggable devices

                                                  [*]   Enable support
for printk

                [*]   BUG() support

                                                      [*]   Enable ELF
core dumps

                      [*]   Enable full-sized data structures for core

                                                             [*]
Enable futex support

                                 [*]   Enable eventpoll support


[*]   Use full shmem filesystem

                                       [*]   Enable VM event counters
for /proc/vmstat

Processor type and features
[ ] IOMMU support

Then you can disable agpgart

- --
Jeffrey Gardner
Gentoo Developer
Public PGP Key ID: 4A5D8F23
hkp://pgpkeys.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGO286iR2KxEpdjyMRAn6hAKC9T8xk9+z6vlWYoHhy/3UVBe9PbwCgzLeA
njMBR38aZ3dOeTsXi7kUXnk=
=1tzD
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] AGPART

[Wil Reichert]

On 5/4/07, Jeffrey Gardner <je_fro@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel Iliev wrote:
> > Hi, guys
> >
> > I have an NForce based motherboard with an integrated
> > [ surprise! ] :) NVidia PCI-X videocard. So, I don't need the agpart
> > driver for my kernel, right? The problem is that I can't switch it off:
> >
> >
> >> Linux Kernel v2.6.20-gentoo-r7 Configuration
> >>      Device Drivers
> >>              Character devices
> >>                       --- /dev/agpgart (AGP Support)
> >
> >
> > The help says:
> >
> >> Selected by: IOMMU && PCI || FB_I810 && FB && EXPERIMENTAL && PCI &&
> >> X86_32 || FB_INTEL && FB && EXPERIMENTAL && PCI && X86
> >
> >
> > My questions:
> > - Is it normal?
> > - Should I disable it (how)?
>
> General setup
> [*] Configure standard kernel features (for small systems)  --->
> [*]   Enable 16-bit UID system calls
>
>                                      [*]   Sysctl syscall support
>
>
>    [*]   Load all symbols for debugging/ksymoops
>
>                                         [ ]     Do an extra kallsyms
> pass
>
>            [*]   Support for hot-pluggable devices
>
>                                                   [*]   Enable support
> for printk
>
>                 [*]   BUG() support
>
>                                                       [*]   Enable ELF
> core dumps
>
>                       [*]   Enable full-sized data structures for core
>
>                                                              [*]
> Enable futex support
>
>                                  [*]   Enable eventpoll support
>
>
> [*]   Use full shmem filesystem
>
>                                        [*]   Enable VM event counters
> for /proc/vmstat
>
> Processor type and features
> [ ] IOMMU support
>
> Then you can disable agpgart
Does it really matter either way?  I've been curious about this myself.

Wil
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] AGPART

[Jeffrey Gardner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wil Reichert wrote:
> On 5/4/07, Jeffrey Gardner <je_fro@gentoo.org> wrote:
kernel stuff...
> Does it really matter either way?  I've been curious about this myself.
> 
> Wil

It used to be that I got many more FPS by disabling agpgart and just use
nvidias. I don't know about nowadays because I've just carried on using
nvidia without ever going back to check.

- --
Jeffrey Gardner
Gentoo Developer
Public PGP Key ID: 4A5D8F23
hkp://pgpkeys.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGO3+uiR2KxEpdjyMRAowkAJ9Q83mlsN/5t5CykdLFIPJYyGZxywCgswSi
fsVMglDmVpBy/M6Zu9J9Xsg=
=Ju/7
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: [OT] AGPART

[Duncan]

Jeffrey Gardner <je_fro@gentoo.org> posted 463B6F3A.9050000@gentoo.org,
excerpted below, on  Fri, 04 May 2007 12:36:58 -0500:

> Processor type and features
> [ ] IOMMU support

Note that for AMD64, if you have >3.5 gig memory, you'll WANT IOMMU 
support, which uses the APGART hardware on AMD.  On Intel, they don't 
have a hardware IOMMU but the kernel emulates it, using the same basic 
options, so I believe you'll want it there as well.

Only four gig of memory is addressable from legacy 32-bit PCI devices, 
and there's a memory hole at the top of 4-gig memory (so beyond 3.5 gig) 
in ordered to allow device i/o memory access.  With the correct BIOS 
settings, the machine will remap the unavailable memory behind that 
memory hole above 4 gig, but it and any memory you had beyond 4 gig 
already will not be directly accessible to DMA and the like from those 
legacy 32-bit PCI devices.  IOMMU = input/output memory management unit.  
The hardware device maps high memory onto accessible addresses in the 
memory hole for the devices that need it, and of course the software 
emulation necessary for Intel machines does the same thing.  

Without that IOMMU, access to that > 4 gig area (because of the memory 
hole, to memory above ~3.5 gig) will be limited, and much slower for some 
devices if they work at all.  Here, I simply cannot boot without IOMMU 
support (unless I disable part of my memory), as the kernel panics when 
it tries to read my hard drives.  Apparently, either the SATA chipset 
they use or the kernel drivers supporting them are legacy 32-bit, and 
without the IOMMU, they simply cannot see the memory they are supposed to 
be DMAing stuff into.

Of course, if you are still on legacy 32-bit x86 or have < 3.5 gig of 
memory (or are on a different arch entirely), the rules are somewhat 
different.  I'm not sure how the IOMMU may be used there, or how much 
attempting to do without it might slow things down.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] AGPART [SOLVED]

[Daniel Iliev]

Thanks, guys!

I knew it was IOMMU, as stated in the help section I quoted in the
first message. I had seen "IOMMU=y" in my .config, but I couldn't find
it anywhere in "menuconfig" in order to disable it. So, Jeffrey
Gardner's response helped me "fix" it. I've always been disabling that
"Small Systems" section because of it's name "CONFIG_EMBEDDED" and
because of the statement "change this stuff only if you know what ya
doin'". So, IOMMU was hidden and auto-enabled.

Duncan, thanks for your most detailed answer. Now I know an additional
thing that should be done when compiling a kernel for systems with >3.5G
RAM. Unfortunately I've got no such "problem" ;-) and I'm happy with
my 1G of RAM. It gets rarely used at 100%. Actually only in situations
like compilation of updated packages + web surfing in the same time.
Beryl and Firefox are my biggest resident memory hogs.

Have a nice weekend, people! :)


-- 
Best regards,
Daniel

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: [OT] AGPART [SOLVED]

[Duncan]

Daniel Iliev <danny@ilievnet.com> posted
20070505075815.DE6FA92266@mail.ilievnet.com, excerpted below, on  Sat, 05
May 2007 10:58:13 +0300:

> Duncan, thanks for your most detailed answer. Now I know an additional
> thing that should be done when compiling a kernel for systems with >3.5G
> RAM. Unfortunately I've got no such "problem" ;-) and I'm happy with my
> 1G of RAM. It gets rarely used at 100%. Actually only in situations like
> compilation of updated packages + web surfing in the same time. Beryl
> and Firefox are my biggest resident memory hogs.

Well, 4 gigs RAM or so opens some real nice possibilities, particularly 
on Gentoo.  Among other things, one can point PORTAGE_TMPDIR at a tmpfs, 
and compile most things entirely in memory! =8^)  Of course, not only 
does that speed up compiles significantly, but it decreases I/O 
contention, so the rest of your system, especially read/write to disk, 
remains much more responsive during compiles.  Combine that with 
MAKEOPTS="-j1" on a dual-core or dual CPU, and/or PORTAGE_NICENESS=19, 
and compiles don't bother you at all.

However, for normal use, 2 gigs seems a very good balance, as at least 
here. I'll run half a gig to a gig of app memory, leaving a gig of memory 
for cache.  With a gig of memory, the system still works very well, but 
most of cache is thrown away during memory intensive tasks (like some 
compiles, or working with large image files or the like), and I really /
hate/ to see that happen, when I know I'll only have to read that data 
back in from disk later.  Two gigs is enough to use a gig of app memory 
at times and still have a gig of cache that's doesn't have to be thrown 
out on top of that, so it's a nice sweet spot.

Actually, here, I have 8 gigs.  That's a bit overkill.  I'd probably 
stick with four if I were doing it over, as over four gigs remains 
entirely empty, most of the time, not even used for cache.  Still, I have 
dual Opterons now, and was buying with dual-cores in mind.  8 gig of 
memory should still be plenty with dual dual-cores, even out three more 
years, which is when I expect to start getting serious about upgrading my 
entire platform once again.  So the 8 gig was future-proofing, and I 
certainly accomplished that.  Still, it's the first time I can honestly 
say I've had so much memory I rarely fill it up, even with cache, and 
it's nice to have had the experience at least /once/ in my life. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: [OT] AGPART [SOLVED]

[Peter Humphrey]

On Saturday 05 May 2007 10:15:41 Duncan wrote:

> Actually, here, I have 8 gigs.  That's a bit overkill.  I'd probably
> stick with four if I were doing it over, as over four gigs remains
> entirely empty, most of the time, not even used for cache.

Glad to see I got it right, 3.5 years ago   :-)

Here also, my 4 GB is at least half-empty unless I'm compiling a large 
package like OO.o. My two single-core Opteron 246 CPUs have plenty of 
playing space.

> Still, I have dual Opterons now, and was buying with dual-cores in mind.

My experience suggests that you would still have been pretty comfortable 
with 4 GB.

> 8 gig of memory should still be plenty with dual dual-cores, even out
> three more years, ...

Well, of course much can happen in that time, so you may be proved right 
after all.

> which is when I expect to start getting serious about upgrading my entire
> platform once again.

Don't talk about it, all right? Just don't talk about it.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: [OT] AGPART [SOLVED]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Saturday 05 May 2007, Duncan <1i5t5.duncan@cox.net> wrote 
about '[gentoo-amd64]  Re: [OT] AGPART [SOLVED]':
> Actually, here, I have 8 gigs.  That's a bit overkill.  I'd probably
> stick with four if I were doing it over, as over four gigs remains
> entirely empty, most of the time, not even used for cache.

Odd, here I run 4G and it's consistently filled.  It's mostly cache and 
buffers, but it is most definitely used.  I've even got a few 100Mio 
swapped out.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: [OT] AGPART [SOLVED] DRIFT: RAM USAGE

[Daniel Iliev]

On Sat, 5 May 2007 09:15:41 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
--snip--
> 
> Actually, here, I have 8 gigs.  That's a bit overkill.  I'd probably 
> stick with four if I were doing it over, as over four gigs remains 
> entirely empty, most of the time, not even used for cache.
--snip--

In case you didn't know...

There are several kernel configuration options you can tweak to make it
cache more aggressively. Also you could try XFS - it is known to be one
of the most hungry-for-RAM file systems. Please, have in mind that
these tweaks could be dangerous for your file system in case of power
failure. Consider using an UPS.

So, you could try changing the values of the following params
in /etc/sysctl.conf and activate their new values by "sysctl -p"

vm.overcommit_memory 
fs.xfs.xfsbufd_centisecs
fs.xfs.xfssyncd_centisecs 
fs.xfs.age_buffer_centisecs 
vm.dirty_ratio 
vm.dirty_background_ratio
vm.dirty_expire_centisecs
vm.dirty_writeback_centisecs
vm.swappiness 
vm.swap_token_timeout 
vm.vfs_cache_pressure 
vm.page-cluster

The  meanings of these options are described in the kernel docs, so the
files containing the info could be found by grepping like:
"grep -rinm1 dirty_expire_centisecs /usr/src/linux/Documentation". 

Have fun! ;-)

-- 
Best regards,
Daniel

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: [OT] AGPART [SOLVED] DRIFT: RAM USAGE

[Duncan]

Daniel Iliev <danny@ilievnet.com> posted
20070506083444.279A29148B@mail.ilievnet.com, excerpted below, on  Sun, 06
May 2007 11:34:42 +0300:

> In case you didn't know...
> 
> There are several kernel configuration options you can tweak to make it
> cache more aggressively. Also you could try XFS - it is known to be one
> of the most hungry-for-RAM file systems. Please, have in mind that these
> tweaks could be dangerous for your file system in case of power failure.
> Consider using an UPS.

I knew about these in general, but still good to post as others may not.

You are talking write-caching here.  I generally leave that pretty much 
alone, for the reasons you mention (corruption in case of kernel panic 
and/or power failure).  That's also why I've chosen not to run XFS.  (I 
run reiserfs and while I did have issues some years ago, early kernel 
2.4, I've had none since the introduction of data=ordered journaling and 
that as the default, even when I had faulty memory and was having fairly 
regular kernel panics as a result.  I wouldn't have wanted to try that 
with big write caches and/or XFS!)

The caching I had in mind was read caching.  No risk there. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Memory usage Was: [OT] AGPART [SOLVED]

[Duncan]

"Boyd Stephen Smith Jr." <bss03@volumehost.net> posted
200705050856.32180.bss03@volumehost.net, excerpted below, on  Sat, 05 May
2007 08:56:27 -0500:

> On Saturday 05 May 2007, Duncan <1i5t5.duncan@cox.net> wrote about
> '[gentoo-amd64]  Re: [OT] AGPART [SOLVED]':
>> Actually, here, I have 8 gigs.  That's a bit overkill.  I'd probably
>> stick with four if I were doing it over, as over four gigs remains
>> entirely empty, most of the time, not even used for cache.
> 
> Odd, here I run 4G and it's consistently filled.  It's mostly cache and
> buffers, but it is most definitely used.  I've even got a few 100Mio
> swapped out.

It's probably just usage patterns.  After awhile up, I'll have serious 
cache, but there's several things that prevents it from getting too big 
most of the time.  

1) I swsusp to disk fairly frequently (every day or two, generally).  
That dumps cache, so I start over when I resume.  (OTOH, swsusp also 
means I too carry some swapped out stuff, generally ~120-200 MB that 
never swaps back in between suspends.)  

2) I run MAKEOPTS=-j1000. (Why?  Mainly just because I can! =8^)  Few 
merges split even 100 jobs, but some of them do (it's really fun watching 
the minute load average jump up and up and up to peak at 500 or so, 
compiling the kernel! =8^), and it's not entirely unusual for C++ jobs to 
use a gig or more of memory for a single job.  Since I also run parallel 
merges on occasion, it's not unusual at all for me to see 2-3 gigs of 
temporary (maybe two minutes, peaking for just a few seconds) application 
memory in use by portage jobs, in addition to the half gig to gig of 
regular app memory in use, and the possibly several gigs of tmpfs 
PORTAGE_TMPDIR in use as scratch space by parallel merges.  Of course, 
that squeezes out regular cache, and I often see memory use including 
cache drop by four gigs, sometimes more, from peak merge usage to post 
merge.

3) I don't run the indexer for slocate.  In fact, I don't even have it 
merged.  On a lot of systems, that's the big daily cache gobbler right 
there.  If it's indexing 50 gigs of disk files, pretty moderate by 
today's standards, it'd fill 50 gigs of cache memory, if it had it to 
fill.  Obviously, anyone who runs that is going to have a full cache 
until they do something that grabs the memory and then releases it, no 
matter /what/ their memory size (within reason).

4) My actual daily working fileset isn't that great.  When I play music, 
it's often off the net, not off my disk, so I'm not using disk for that.  
I don't have the big movie cache many have.  I don't play gigabytes worth 
of games.  Etc.  I have gigs of files, but don't tend to use them daily, 
and with swsusp every day or two, and running many of the kernel rcs and 
sometimes even the daily git snapshots (not to mention when I have a 
kernel bug open and I'm rebooting new kernel builds multiple times a 
day), many times I just don't actually /read/ (or write, since those 
would be cached after write as well) multiple gigs of files between cache-
dumps.

So as I said, practically speaking, four gigs of memory would be plenty, 
as I'd be a bit more conservative on my merges then, and would figure 2-3 
gigs of cache and 1-2 gigs of app memory most of the time.

(Right now, after returning from swsusp a few hours ago, and spending 
most of my time since in the text groups/lists, I'm running about 200 MB 
still swapped out from the suspend, and total memory use, app, buffer, 
and cache, of only ~1/2 GB.  That's as displayed on ksysguard, with KDE 
including kmail and amarok in the system tray, and pan open to read and 
reply to the lists (gmane list2news gateway) with, all started before my 
last swsusp, so only the apps and state I've actually used since then 
have been swapped back in.  If I closed and reopened pan, so it had to 
reread its lists, and ran an emerge --pretend world, to recache that 
info, I'd be back up at a gig to a gig and a half total usage, cache 
included, probably.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list