- 24 6月, 2005 2 次提交
-
-
由 Christoph Lameter 提交于
It allows a selectable timer interrupt frequency of 100, 250 and 1000 HZ. Reducing the timer frequency may have important performance benefits on large systems. Signed-off-by: NChristoph Lameter <clameter@sgi.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Dave Hansen 提交于
For all architectures, this just means that you'll see a "Memory Model" choice in your architecture menu. For those that implement DISCONTIGMEM, you may eventually want to make your ARCH_DISCONTIGMEM_ENABLE a "def_bool y" and make your users select DISCONTIGMEM right out of the new choice menu. The only disadvantage might be if you have some specific things that you need in your help option to explain something about DISCONTIGMEM. Signed-off-by: NDave Hansen <haveblue@us.ibm.com> Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 6月, 2005 3 次提交
-
-
由 Jes Sorensen 提交于
This patch contains the bits to make the XPC code use the uncached allocator rather than calling into the mspec driver. It also includes the mspec.h header which is required to build the XPC modules. Signed-off-by: NJes Sorensen <jes@wildopensource.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jes Sorensen 提交于
This patch contains the ia64 uncached page allocator and the generic allocator (genalloc). The uncached allocator was formerly part of the SN2 mspec driver but there are several other users of it so it has been split off from the driver. The generic allocator can be used by device driver to manage special memory etc. The generic allocator is based on the allocator from the sym53c8xx_2 driver. Various users on ia64 needs uncached memory. The SGI SN architecture requires it for inter-partition communication between partitions within a large NUMA cluster. The specific user for this is the XPC code. Another application is large MPI style applications which use it for synchronization, on SN this can be done using special 'fetchop' operations but it also benefits non SN hardware which may use regular uncached memory for this purpose. Performance of doing this through uncached vs cached memory is pretty substantial. This is handled by the mspec driver which I will push out in a seperate patch. Rather than creating a specific allocator for just uncached memory I came up with genalloc which is a generic purpose allocator that can be used by device drivers and other subsystems as they please. For instance to handle onboard device memory. It was derived from the sym53c7xx_2 driver's allocator which is also an example of a potential user (I am refraining from modifying sym2 right now as it seems to have been under fairly heavy development recently). On ia64 memory has various properties within a granule, ie. it isn't safe to access memory as uncached within the same granule as currently has memory accessed in cached mode. The regular system therefore doesn't utilize memory in the lower granules which is mixed in with device PAL code etc. The uncached driver walks the EFI memmap and pulls out the spill uncached pages and sticks them into the uncached pool. Only after these chunks have been utilized, will it start converting regular cached memory into uncached memory. Hence the reason for the EFI related code additions. Signed-off-by: NJes Sorensen <jes@wildopensource.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Greg Edwards 提交于
Allow the SGI simulator (medusa) to work on generic kernels. There is no inherent dependency on an sn2-specific kernel. Boot tested on Altix, medusa and HP rx2600. Signed-off-by: NGreg Edwards <edwardsg@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 06 5月, 2005 1 次提交
-
-
由 Anton Blanchard 提交于
While looking at code generated by gcc4.0 I noticed some functions still had frame pointers, even after we stopped ppc64 from defining CONFIG_FRAME_POINTER. It turns out kernel/Makefile hardwires -fno-omit-frame-pointer on when compiling schedule.c. Create CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER and define it on architectures that dont require frame pointers in sched.c code. (akpm: blame me for the name) Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 04 5月, 2005 2 次提交
-
-
由 Dean Nelson 提交于
This patch contains the shim module (XP) which interfaces between the communication module (XPC) and the functional support modules (like XPNET). Signed-off-by: NDean Nelson <dcn@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Suresh Siddha 提交于
Now that we have MC/MT detection patches in, appended patch allows us to configure MT scheduler optimizations. For now, we will this option off by default. There is some discussion going on lkml about setting up sched-domains which are absolutely needed (like for example, we shouldn't setup SMT domain for non MT processors). Once that patch goes in, we can enable this option by default. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 26 4月, 2005 1 次提交
-
-
由 Jesse Barnes 提交于
[IA64] fix ia64 Kconfig to allow CONFIG_PM on sn2 This probably should have been fixed when I fixed up the generic build for discontig+numa machines, but oh well. CONFIG_PM is allowable for generic builds but not for sn2 builds, which doesn't make much sense, and in fact breaks the build if recent ACPI bits are added to the tree. It looks like the only arch that needs to prevent CONFIG_PM stuff is the ski simulator (though those options could probably use some cleanup as well), so remove the big conditional and replace it with a simple test for IA64_HP_SIM instead. Signed-off-by: NJesse Barnes <jbarnes@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-