89 messages in org.kernel.vger.linux-kernelRe: [PATCH ] VMSPLIT config options ...
FromSent OnAttachments
Jens AxboeJan 10, 2006 4:58 am 
Ingo MolnarJan 10, 2006 5:29 am 
Jens AxboeJan 10, 2006 5:37 am 
Byron StanoszekJan 10, 2006 5:43 am 
Jens AxboeJan 10, 2006 5:47 am 
Mikael PetterssonJan 10, 2006 5:47 am 
Jens AxboeJan 10, 2006 5:53 am 
Gerd HoffmannJan 10, 2006 6:09 am 
Mark LordJan 10, 2006 6:11 am 
Jens AxboeJan 10, 2006 6:21 am 
Jens AxboeJan 10, 2006 6:22 am 
Jens AxboeJan 10, 2006 6:25 am 
Jens AxboeJan 10, 2006 6:39 am 
Ingo MolnarJan 10, 2006 6:43 am 
Jens AxboeJan 10, 2006 7:03 am 
Mark LordJan 10, 2006 7:11 am.patch
Mikael PetterssonJan 10, 2006 7:23 am 
Linus TorvaldsJan 10, 2006 8:14 am 
Jeff V. MerkeyJan 10, 2006 8:30 am.patch, .patch
Mark LordJan 10, 2006 8:39 am 
Linus TorvaldsJan 10, 2006 8:52 am 
Jeff V. MerkeyJan 10, 2006 8:56 am 
Jeff V. MerkeyJan 10, 2006 9:00 am 
Mark LordJan 10, 2006 9:06 am 
Sergey VlasovJan 10, 2006 9:07 am 
Jeff V. MerkeyJan 10, 2006 9:13 am 
Jeff V. MerkeyJan 10, 2006 9:17 am 
Linus TorvaldsJan 10, 2006 9:28 am 
Jens AxboeJan 10, 2006 9:32 am 
Jeff V. MerkeyJan 10, 2006 9:36 am 
Mark LordJan 10, 2006 9:36 am 
Bernd EckenfelsJan 10, 2006 9:48 am 
Martin BlighJan 10, 2006 10:14 am 
Coywolf Qi HuntJan 10, 2006 10:27 am 
Coywolf Qi HuntJan 10, 2006 10:32 am 
Linus TorvaldsJan 10, 2006 10:34 am 
Martin BlighJan 10, 2006 10:39 am 
Mark LordJan 10, 2006 10:45 am 
Martin BlighJan 10, 2006 10:46 am 
Lennart SorensenJan 10, 2006 10:50 am 
Dave HansenJan 10, 2006 10:54 am 
Mark LordJan 10, 2006 10:57 am 
Jens AxboeJan 10, 2006 10:57 am 
Mark LordJan 10, 2006 11:01 am 
Dave HansenJan 10, 2006 11:04 am 
Jeff V. MerkeyJan 10, 2006 11:12 am 
Mark LordJan 10, 2006 11:15 am 
Jens AxboeJan 10, 2006 11:26 am 
Jeff V. MerkeyJan 10, 2006 11:30 am 
Jens AxboeJan 10, 2006 11:41 am 
Bernd EckenfelsJan 10, 2006 12:17 pm 
Jens AxboeJan 10, 2006 12:27 pm 
Jan EngelhardtJan 10, 2006 12:42 pm 
Alan CoxJan 10, 2006 12:54 pm 
Jens AxboeJan 10, 2006 1:02 pm 
Con KolivasJan 10, 2006 4:25 pm 
J.A. MagallonJan 10, 2006 5:12 pm 
Bernd EckenfelsJan 11, 2006 12:39 am 
Jens AxboeJan 11, 2006 2:05 am 
Jens AxboeJan 11, 2006 2:15 am 
Greg NorrisJan 11, 2006 8:00 am 
Mark LordJan 11, 2006 9:12 am 
Greg NorrisJan 11, 2006 9:44 am 
Herbert PoetzlFeb 1, 2006 2:22 pm 
Ulrich MuellerFeb 2, 2006 3:03 am 
Jan EngelhardtFeb 2, 2006 12:55 pm 
Mark LordFeb 3, 2006 2:38 pm 
Ulrich MuellerFeb 4, 2006 2:22 am 
Jens AxboeFeb 4, 2006 2:35 am 
Jan EngelhardtFeb 4, 2006 3:04 am 
Jan EngelhardtFeb 4, 2006 3:05 am 
Mark LordFeb 4, 2006 5:57 am 
J.A. MagallonFeb 5, 2006 7:32 am 
Arjan van de VenFeb 5, 2006 7:38 am 
Barry K. NathanFeb 5, 2006 10:41 am 
Bodo EggertFeb 5, 2006 12:20 pm 
Jan EngelhardtFeb 5, 2006 1:13 pm 
Arjan van de VenFeb 5, 2006 1:18 pm 
Jeff DikeFeb 5, 2006 2:12 pm 
Jan EngelhardtFeb 6, 2006 6:56 am 
Herbert PoetzlFeb 6, 2006 4:41 pm 
Mark RustadFeb 6, 2006 6:50 pm 
Bernd PetrovitschFeb 7, 2006 1:37 am 
Adrian BunkFeb 7, 2006 4:19 am 
Ulrich MuellerFeb 7, 2006 6:05 am 
Adrian BunkFeb 7, 2006 6:42 am 
Jan EngelhardtFeb 9, 2006 8:06 am 
Kirill KorotaevApr 10, 2006 7:10 am 
Mark LordApr 10, 2006 7:39 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [PATCH ] VMSPLIT config options (with default config fixed)Actions...
From:Jens Axboe (axb@suse.de)
Date:Jan 11, 2006 2:15:01 am
List:org.kernel.vger.linux-kernel

On Wed, Jan 11 2006, J.A. Magallon wrote:

I really like to see this in -mm, and finally in mainline.

It's in -mm now.

My only objection is about the menu entry names and help. I think people building a kernel would not exactly understand what all this is about (even I think I don't have it realle clear).

If they don't, they should not touch the option...

Is there any doc which states clearly somthing like:

- no highmem is the fastest - 4Gb introduces one indirection, so it is slower...(really ?) - 64Gb introduces two (PAE ?)

mixed with

- 3G/1G standard maping: - nor user nor kernel can use any memory above 860 Mb - user processes (my numbercruncher) can not allocate more than XGb - 2G/2G: idem: - max memory seen by my linux system (not kernel, but kernel+userspace, - how much can I allocate for a single process (how big my problem can be ?)

If there is already a doc like that, it would be very interesting to have pointer/link to it in the help text.

I think the help text is good enough, but it would definitely be nice with a fuller description of what exactly low and high memory is and the implications of the various settings.

For example, when I read this:

+ If the address range available to the kernel is less than the + physical memory installed, the remaining memory will be available + as "high memory". Accessing high memory is a little more costly + than low memory, as it needs to be mapped into the kernel first.

Does this mean that with 3/1 standard split, I still can use the lost 128 Mb for something ? I though I can't.

It tells you that the remaining memory is available as high memory, so it's not lost of course. It also tells you that accessing this high memory is indeed possible, but it's a little more costly since it needs to be mapped temporarily into the kernel address space.

Don't be too hard with me, just anxious to finally understand this...

No worries, perhaps you will be the one writing the Documentation/ bit to accompany this then :-)

Basically the option boils down to how much virtual address space you want to assign to the kernel and user space. The kernel can always access all of memory, but in some cases part of that memory will be available as high memory that needs to be mapped in first (see references to kmap() and kmap_atomic() in the kernel). So whether changing the mapping or using highmem is the best option for you, depends entirely on what you run on that machine. If you require a huge user address space, then you don't want to change away from the 3/1 user/kernel default setting. However, if you don't need the full 3G of adress space to user apps, then you are better off increasing the kernel address space range to get rid of the high memory mapping.

For the "typical" case of 1GB machine, using the _OPT setting to just move the offset slightly is a really good choice as it only removes a little bit of the user address range.