

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
89 messages in org.kernel.vger.linux-kernelRe: [PATCH ] VMSPLIT config options ...| From | Sent On | Attachments |
|---|---|---|
| Jens Axboe | Jan 10, 2006 4:58 am | |
| Ingo Molnar | Jan 10, 2006 5:29 am | |
| Jens Axboe | Jan 10, 2006 5:37 am | |
| Byron Stanoszek | Jan 10, 2006 5:43 am | |
| Jens Axboe | Jan 10, 2006 5:47 am | |
| Mikael Pettersson | Jan 10, 2006 5:47 am | |
| Jens Axboe | Jan 10, 2006 5:53 am | |
| Gerd Hoffmann | Jan 10, 2006 6:09 am | |
| Mark Lord | Jan 10, 2006 6:11 am | |
| Jens Axboe | Jan 10, 2006 6:21 am | |
| Jens Axboe | Jan 10, 2006 6:22 am | |
| Jens Axboe | Jan 10, 2006 6:25 am | |
| Jens Axboe | Jan 10, 2006 6:39 am | |
| Ingo Molnar | Jan 10, 2006 6:43 am | |
| Jens Axboe | Jan 10, 2006 7:03 am | |
| Mark Lord | Jan 10, 2006 7:11 am | .patch |
| Mikael Pettersson | Jan 10, 2006 7:23 am | |
| Linus Torvalds | Jan 10, 2006 8:14 am | |
| Jeff V. Merkey | Jan 10, 2006 8:30 am | .patch, .patch |
| Mark Lord | Jan 10, 2006 8:39 am | |
| Linus Torvalds | Jan 10, 2006 8:52 am | |
| Jeff V. Merkey | Jan 10, 2006 8:56 am | |
| Jeff V. Merkey | Jan 10, 2006 9:00 am | |
| Mark Lord | Jan 10, 2006 9:06 am | |
| Sergey Vlasov | Jan 10, 2006 9:07 am | |
| Jeff V. Merkey | Jan 10, 2006 9:13 am | |
| Jeff V. Merkey | Jan 10, 2006 9:17 am | |
| Linus Torvalds | Jan 10, 2006 9:28 am | |
| Jens Axboe | Jan 10, 2006 9:32 am | |
| Jeff V. Merkey | Jan 10, 2006 9:36 am | |
| Mark Lord | Jan 10, 2006 9:36 am | |
| Bernd Eckenfels | Jan 10, 2006 9:48 am | |
| Martin Bligh | Jan 10, 2006 10:14 am | |
| Coywolf Qi Hunt | Jan 10, 2006 10:27 am | |
| Coywolf Qi Hunt | Jan 10, 2006 10:32 am | |
| Linus Torvalds | Jan 10, 2006 10:34 am | |
| Martin Bligh | Jan 10, 2006 10:39 am | |
| Mark Lord | Jan 10, 2006 10:45 am | |
| Martin Bligh | Jan 10, 2006 10:46 am | |
| Lennart Sorensen | Jan 10, 2006 10:50 am | |
| Dave Hansen | Jan 10, 2006 10:54 am | |
| Mark Lord | Jan 10, 2006 10:57 am | |
| Jens Axboe | Jan 10, 2006 10:57 am | |
| Mark Lord | Jan 10, 2006 11:01 am | |
| Dave Hansen | Jan 10, 2006 11:04 am | |
| Jeff V. Merkey | Jan 10, 2006 11:12 am | |
| Mark Lord | Jan 10, 2006 11:15 am | |
| Jens Axboe | Jan 10, 2006 11:26 am | |
| Jeff V. Merkey | Jan 10, 2006 11:30 am | |
| Jens Axboe | Jan 10, 2006 11:41 am | |
| Bernd Eckenfels | Jan 10, 2006 12:17 pm | |
| Jens Axboe | Jan 10, 2006 12:27 pm | |
| Jan Engelhardt | Jan 10, 2006 12:42 pm | |
| Alan Cox | Jan 10, 2006 12:54 pm | |
| Jens Axboe | Jan 10, 2006 1:02 pm | |
| Con Kolivas | Jan 10, 2006 4:25 pm | |
| J.A. Magallon | Jan 10, 2006 5:12 pm | |
| Bernd Eckenfels | Jan 11, 2006 12:39 am | |
| Jens Axboe | Jan 11, 2006 2:05 am | |
| Jens Axboe | Jan 11, 2006 2:15 am | |
| Greg Norris | Jan 11, 2006 8:00 am | |
| Mark Lord | Jan 11, 2006 9:12 am | |
| Greg Norris | Jan 11, 2006 9:44 am | |
| Herbert Poetzl | Feb 1, 2006 2:22 pm | |
| Ulrich Mueller | Feb 2, 2006 3:03 am | |
| Jan Engelhardt | Feb 2, 2006 12:55 pm | |
| Mark Lord | Feb 3, 2006 2:38 pm | |
| Ulrich Mueller | Feb 4, 2006 2:22 am | |
| Jens Axboe | Feb 4, 2006 2:35 am | |
| Jan Engelhardt | Feb 4, 2006 3:04 am | |
| Jan Engelhardt | Feb 4, 2006 3:05 am | |
| Mark Lord | Feb 4, 2006 5:57 am | |
| J.A. Magallon | Feb 5, 2006 7:32 am | |
| Arjan van de Ven | Feb 5, 2006 7:38 am | |
| Barry K. Nathan | Feb 5, 2006 10:41 am | |
| Bodo Eggert | Feb 5, 2006 12:20 pm | |
| Jan Engelhardt | Feb 5, 2006 1:13 pm | |
| Arjan van de Ven | Feb 5, 2006 1:18 pm | |
| Jeff Dike | Feb 5, 2006 2:12 pm | |
| Jan Engelhardt | Feb 6, 2006 6:56 am | |
| Herbert Poetzl | Feb 6, 2006 4:41 pm | |
| Mark Rustad | Feb 6, 2006 6:50 pm | |
| Bernd Petrovitsch | Feb 7, 2006 1:37 am | |
| Adrian Bunk | Feb 7, 2006 4:19 am | |
| Ulrich Mueller | Feb 7, 2006 6:05 am | |
| Adrian Bunk | Feb 7, 2006 6:42 am | |
| Jan Engelhardt | Feb 9, 2006 8:06 am | |
| Kirill Korotaev | Apr 10, 2006 7:10 am | |
| Mark Lord | Apr 10, 2006 7:39 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread 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.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majo...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/








.patch