- 10 Mar, 2005 40 commits
-
-
Randy Dunlap authored
Fix radeonfb section references by changing __initdata to __devinitdata. Error: ./drivers/video/radeonfb.o .text refers to 0000000000002037 R_X86_64_PC32 .init.data+0x0000000000000003 Error: ./drivers/video/radeonfb.o .text refers to 0000000000002491 R_X86_64_PC32 .init.data Error: ./drivers/video/radeonfb.o .text refers to 0000000000002870 R_X86_64_PC32 .init.data+0x000000000000000c Error: ./drivers/video/radeonfb.o .text refers to 0000000000002a21 R_X86_64_PC32 .init.data+0xfffffffffffffffb Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Randy Dunlap authored
Fix pm2fb section references by changing referenced __initdata to __devinitdata. Error: ./drivers/video/pm2fb.o .text refers to 0000000000000ad4 R_X86_64_PC32 .init.data+0x0000000000000007 Error: ./drivers/video/pm2fb.o .text refers to 0000000000000afc R_X86_64_PC32 .init.data+0x0000000000000003 Error: ./drivers/video/pm2fb.o .text refers to 000000000000147e R_X86_64_PC32 .init.data+0x00000000000000bc Error: ./drivers/video/pm2fb.o .text refers to 0000000000001491 R_X86_64_PC32 .init.data+0x00000000000000c2 Error: ./drivers/video/pm2fb.o .text refers to 000000000000149a R_X86_64_PC32 .init.data+0x00000000000000bc Error: ./drivers/video/pm2fb.o .text refers to 00000000000014aa R_X86_64_32S .init.data+0x00000000000000c0 Error: ./drivers/video/pm2fb.o .text refers to 00000000000014e0 R_X86_64_PC32 .init.data+0x00000000000000f8 Error: ./drivers/video/pm2fb.o .text refers to 00000000000014eb R_X86_64_PC32 .init.data+0x00000000000000f4 Error: ./drivers/video/pm2fb.o .text refers to 000000000000150e R_X86_64_PC32 .init.data+0x00000000000000fc Error: ./drivers/video/pm2fb.o .text refers to 0000000000001515 R_X86_64_PC32 .init.data+0x00000000000000f4 Error: ./drivers/video/pm2fb.o .text refers to 000000000000152d R_X86_64_32S .init.data+0x00000000000000c0 Error: ./drivers/video/pm2fb.o .text refers to 00000000000015ce R_X86_64_PC32 .init.data+0x00000000000000cc Error: ./drivers/video/pm2fb.o .text refers to 00000000000015d7 R_X86_64_PC32 .init.data+0x00000000000000d4 Error: ./drivers/video/pm2fb.o .text refers to 00000000000015fa R_X86_64_PC32 .init.data+0x00000000000000d4 Error: ./drivers/video/pm2fb.o .text refers to 0000000000001601 R_X86_64_PC32 .init.data+0x00000000000000cc Error: ./drivers/video/pm2fb.o .text refers to 0000000000001644 R_X86_64_32S .init.data+0x00000000000000c0 Error: ./drivers/video/pm2fb.o .text refers to 0000000000001674 R_X86_64_PC32 .init.data+0xfffffffffffffffc Error: ./drivers/video/pm2fb.o .text refers to 000000000000168e R_X86_64_PC32 .init.data+0xfffffffffffffffc Error: ./drivers/video/pm2fb.o .text refers to 00000000000016af R_X86_64_32S .init.data+0x0000000000000020 Error: ./drivers/video/pm2fb.o .text refers to 0000000000001724 R_X86_64_PC32 .init.data+0x00000000000000d4 Error: ./drivers/video/pm2fb.o .text refers to 000000000000172b R_X86_64_PC32 .init.data+0x00000000000000cc Error: ./drivers/video/pm2fb.o .text refers to 0000000000001746 R_X86_64_PC32 .init.data+0x00000000000000fc Error: ./drivers/video/pm2fb.o .text refers to 000000000000174d R_X86_64_PC32 .init.data+0x00000000000000f4 Signed-off-by:
-
Randy Dunlap authored
Fix neofb section reference to __initdata: make it __devinitdata. Error: ./drivers/video/neofb.o .text refers to 0000000000001fb4 R_X86_64_PC32 .init.data+0xfffffffffffffffc Signed-off-by:
-
Randy Dunlap authored
Fix kyro sections references by changing __initdata to __devinitdata. Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000692 R_X86_64_PC32 .init.data+0x000000000000090c Error: ./drivers/video/kyro/fbdev.o .text refers to 00000000000006c2 R_X86_64_PC32 .init.data+0x0000000000000914 Error: ./drivers/video/kyro/fbdev.o .text refers to 00000000000006d1 R_X86_64_PC32 .init.data+0x0000000000000934 Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000709 R_X86_64_PC32 .init.data+0x0000000000000934 Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000711 R_X86_64_PC32 .init.data+0x000000000000093c Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000727 R_X86_64_PC32 .init.data+0x000000000000090c Error: ./drivers/video/kyro/fbdev.o .text refers to 000000000000072d R_X86_64_PC32 .init.data+0x0000000000000914 Error: ./drivers/video/kyro/fbdev.o .text refers to 000000000000073f R_X86_64_PC32 .init.data+0x00000000000008eb Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000748 R_X86_64_PC32 .init.data+0x0000000000000914 Error: ./drivers/video/kyro/fbdev.o .text refers to 000000000000075b R_X86_64_PC32 .init.data+0x000000000000090c Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000778 R_X86_64_32S .init.data+0x0000000000000900 Error: ./drivers/video/kyro/fbdev.o .text refers to 000000000000077e R_X86_64_PC32 .init.data+0x00000000000008e7 Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000793 R_X86_64_PC32 .init.data+0x0000000000000926 Error: ./drivers/video/kyro/fbdev.o .text refers to 000000000000079b R_X86_64_PC32 .init.data+0x00000000000008e3 Error: ./drivers/video/kyro/fbdev.o .text refers to 00000000000007a6 R_X86_64_PC32 .init.data+0x0000000000000928 Error: ./drivers/video/kyro/fbdev.o .text refers to 00000000000007f1 R_X86_64_PC32 .init.data+0x00000000000008dc Error: ./drivers/video/kyro/fbdev.o .text refers to 00000000000007f8 R_X86_64_32S .init.data+0x0000000000000420 Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000805 R_X86_64_32S .init.data+0x00000000000000a0 Error: ./drivers/video/kyro/fbdev.o .text refers to 0000000000000834 R_X86_64_32S .init.data Signed-off-by:
-
Randy Dunlap authored
Fix imsttfb section references: change __initdata to __devinitdata and __init to __devinit. Error: ./drivers/video/imsttfb.o .text refers to 000000000000103b R_X86_64_32S .init.data+0x0000000000000040 Error: ./drivers/video/imsttfb.o .text refers to 0000000000001049 R_X86_64_32S .init.data+0x0000000000000041 Error: ./drivers/video/imsttfb.o .text refers to 0000000000001064 R_X86_64_32S .init.data Error: ./drivers/video/imsttfb.o .text refers to 0000000000001071 R_X86_64_32S .init.data+0x0000000000000001 Signed-off-by:
-
Randy Dunlap authored
Fix atyfb references to __initdata from .text code sections by changing __initdata to __devinitdata. Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002416 R_X86_64_32S .init.data+0x00000000000004a0 Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002514 R_X86_64_32S .init.data Error: ./drivers/video/aty/atyfb_base.o .text refers to 000000000000253e R_X86_64_32S .init.data+0x0000000000000060 Error: ./drivers/video/aty/atyfb_base.o .text refers to 00000000000026c4 R_X86_64_32S .init.data+0x00000000000004a0 Error: ./drivers/video/aty/atyfb_base.o .text refers to 00000000000026e7 R_X86_64_32S .init.data+0x0000000000000070 Error: ./drivers/video/aty/atyfb_base.o .text refers to 00000000000026ee R_X86_64_32S .init.data+0x0000000000000068 Error: ./drivers/video/aty/atyfb_base.o .text refers to 00000000000026fa R_X86_64_32S .init.data+0x0000000000000074 Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002706 R_X86_64_32S .init.data+0x0000000000000078 Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002712 R_X86_64_32S .init.data+0x000000000000007c Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002afb R_X86_64_32S .init.data+0x0000000000000560 Error: ./drivers/video/aty/atyfb_base.o .text refers to 0000000000002baa R_X86_64_32S .init.data+0x00000000000004c0 Signed-off-by:
-
Randy Dunlap authored
asiliantfb refers to __initdata that should be __devinitdata and calls __init functions that should be __devinit; Error: ./drivers/video/asiliantfb.o .text refers to 00000000000006ee R_X86_64_32S .init.data+0x00000000000000a0 Error: ./drivers/video/asiliantfb.o .text refers to 0000000000000711 R_X86_64_32S .init.data Signed-off-by:
-
Benjamin Herrenschmidt authored
So you remember all those weird lockups at boot that happened in late 2.6.11-rc with radeonfb. I posted a "workaround" which just moved code around a bit and it appeared to work. I finally got some real infos about the problem from ATI, and it seems my "workaround" is not very safe and there are other potential issues realted to HW bugs when accessing the PLL registers. This patch implements all of these workarounds (and puts back the code where it was before my previous fix). Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Antonino Daplas authored
This patch contains cleanups including the following: - make needlessly global code static - remove the needlessly #ifdef MODULE from several module_exit - remove or #if 0 the following unused global functions: - fbmon.c: fb_create_modedb - fbmon.c: fb_get_monitor_limits - nvidia/nv_i2c.c: nvidia_delete_i2c_busses - nvidia/nv_setup.c: NVEnablePalette - nvidia/nv_setup.c: NVReadDacMask - remove the following unneeded EXPORT_SYMBOL's: - fbmon.c: fb_create_modedb - fbmon.c: fb_get_monitor_limits - hgafb.c: hgafb_setup Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino Daplas authored
#if defined(CONFIG_FB_SAVAGE_ACCEL) doesn't work with FB_SAVAGE_ACCEL=m, and #if defined(CONFIG_FB_SAVAGE_ACCEL) || defined(CONFIG_FB_SAVAGE_ACCEL_MODULE) would break with FB_SAVAGE=y and FB_SAVAGE_ACCEL=m. Rename savagefb.c to savagefb_driver.c. Signed-off-by:
-
Jon Smirl authored
Allow the framebuffer core to be built as a module to ease debugging. Signed-off-by:
-
James Simmons authored
Replaced LONG_MASK, SHIFT_PER_LONG, BYTES_PER_LONG with dynamic variables. This will allow drivers in the future to control how much data to read/write from the framebuffer. Signed-off-by:
-
Antonino Daplas authored
The Geforce2 cards crashes at 800x600-8, but not at 640x480 or 1024x768. Changing the xres_virtual to be divisible by 64 fixes the problem. Signed-off-by:
-
Antonino Daplas authored
Fixed error handling in rivafb-i2c.c if bus registration fails. Signed-off-by:
-
Antonino Daplas authored
Fixed error handling in rivafb-i2c.c if bus registration fails. Signed-off-by:
-
Antonino Daplas authored
From Jiri Benc: we found several bugs in framebuffer console code in recent kernels. 1. The escape sequence '\033[?25l' does not work (should disable cursor). 2. When scrolling console using Shift-PgUp with cursor in the upper half part of the screen, cursor position is not updated. 3. If cursor is placed at some character and console is scrolled using Shift-PgUp, that character remains on the screen. Signed-off-by:
-
Antonino Daplas authored
Add capability to change private modelist. It checks if the entries in the new modelist are acceptable, and if not, trimmed from the modelist. Also added a new event, FB_EVENT_NEW_MODELIST, sent by fbmem, and captured by fbcon to resize all consoles, if need be. Requires minor changes to new functions, ie, fb_get_color_depth(). Signed-off-by:
-
Jon Smirl authored
This is a first pass at adding two new sysfs attributes to /sys/class/graphics/fb0 for setting modes. There are two attributes: modes which contains a list of valid modes, and mode which is the current mode. To switch modes echo one of the entries from the modes list to the mode attribute. The D,V,S on the modes represents Detailed, Vesa, Standard from the DDC info. modes is root writable. It can also be used to set the list of modes. For example a /etc file could add modes that are not in the monitor's DDC. mode is user writable. PAM would set ownership of mode at user login time. This provides a safe way for a user to set the mode without being root. You can only set the mode to one of the modes on the list. Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch adds suspend/resume support to the Apple UniNorth AGP bridge to make sure AGP is properly disabled when the machine goes to sleep. Without this, the r300 based laptops will fail to wakeup from sleep when using the new experimental r300 DRI driver. It should also improve reliablility in general with other chips. Unfortunately, uninorth-agp is just a "sibling" of the video chip on the PCI bus, and thus ends up beeing called either before the video chip suspend routine, or after, depending on the HW layout or other random things. To make sure the device side of AGP is always disabled first and that we never touch the device after having put it into D2 state (which can be deadly), I also need the separate patch to radeonfb and aty128fb which will make them disabled their own side if not already done by the bridge driver. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch improves reliability of suspend/resume by making sure AGP is disabled on the Rage 128 chip before putting it into a suspend state. It works in conjunction with the uninorth-agp suspend patch, but should be harmless on machines with a different AGP bridge. Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch improves reliability of suspend/resume by making sure AGP is disabled on the radeon chip before putting it into a suspend state. It works in conjunction with the uninorth-agp suspend patch, but should be harmless on machines with a different AGP bridge. Signed-off-by:
-
Antonino Daplas authored
From Ulrich Eckhardt: * removed trailing whitespace * use helper function for common bitwise operations * fixed several cases where either the wrong mask was used for bitops or the mask was computed falsely, messing up <32 BPP support * added self-tests for bitcpy_rev() algorithm in module-init function * no need to use explicitly sized integers in some cases * added a few comments where things weren't obvious to me I tested these changes on an Au1100 based board, using the patches to its framebuffer code that were posted here by Christian Pellegrin[1]. I had this code working both on a 16BPP color LCD and a 4BPP monochrome one. Signed-off-by: -
Antonino Daplas authored
Because nVidia keeps pumping out new graphics chipsets, it is becoming harder to add support for these with the old rivafb code. Currently, rivafb can properly support NV_ARCH_20 chipsets and older. Instead of rewriting rivafb to support the latest chipsets, I've decided to write a new driver, called nvidiafb. The aim is to closely follow Xorg development. Currently, this driver is based on the most recent CVS Xorg nv driver. Main - console acceleration for all chipsets - uses DMA instead of PIO - better LCD/digital output support - better monitor detection - support for Riva128 will be dropped as it cannot do DMA, rivafb will remain as the driver for this chipset It should work with Xorg/XFree86 nv driver, but as with rivafb, is not compatible with the proprietary nvidia driver. Once the code becomes stable, rivafb code will be trimmed to only support the Riva128 and perhaps some of the older chipsets. The code has been tested on several nVidia graphics card on x86 and x86_64. I'm still waiting for feedback from Guido Guenther regarding ppc. This need not go to mainline immediately, as I would prefer the code to receive rigorous testing in the mm tree. Signed-off-by: -
Antonino Daplas authored
Attached is a patch (against 2.6.10) for a framebuffer driver for the Geode family of processors. It does not use AMD's horrible Durango API. It is, however, rather feature incomplete at the moment. * Only Geode GX1 (with CS5530 companion chip) is supported. * Tested resolutions: 640x480 to 1280x1024. * Supported bit depths: 8 bit palette, 16 bit RGB 5-6-5. * CRT output only. * No accelerated features. * Compression is not enabled. * flat panel support (panel=<x>x<y> option). (Only one 640x480 panel has been tested though.) * blank function for display blanking/powersaving. * crt=<n> option to enable/disable the CRT output. From: Alexey Dobriyan <adobriyan@mail.ru> Fix drivers/video/geode/display_gx1.c: error: `loops_per_jiffy' undeclared (first use in this function) drivers/video/geode/video_cs5530.c: error: `loops_per_jiffy' undeclared (first use in this function) Signed-off-by:David Vrabel <dvrabel@arcom.com> Signed-off-by:
Alexey Dobriyan <adobriyan@mail.ru> Signed-off-by:
-
David Vrabel authored
This set of two patches add new options (FB_CFB_IMAGEBLIT, FB_CFB_FILLRECT, FB_CFB_COPYAREA, FB_SOFT_CURSOR) to the framebuffer Kconfig to enable building the generic software cfbfillrect, cfbcopyarea, cfbimageblt and softcursor objects. This cuts out a lot of stuff from the Makefile and allows drivers in their own directory to be more self-contained. Signed-off-by:
-
Antonino Daplas authored
This patch fixes a few bugs with the low level logo code. 1. Allow DEC Alpha machines to draw the DEC logo 2. Cleanup the logo directory on a make clean 3. Some makefile cleanups. I have tested on my local machines. I like to be able to create the C files from the logos for only the ones we want to compile but I haven't figured out how to do that. That can wait. Please apply. Signed-off-by:
James Simmons <jsimmons@www.infradead.org> Signed-off-by:
-
Antonino Daplas authored
The recent intelfb update made intelfb pass vesa_modes as the database to fb_find_mode(). The array vesa_modes depends on CONFIG_FB_MODEHELPERS. Fix Signed-off-by:
-
Andrew Morton authored
drivers/video/tridentfb.c:1219: warning: `tridentfb_setup' declared `static' but never defined Signed-off-by:
-
Adrian Bunk authored
This patch makes some needlessly global code static. Signed-off-by:
-
Andrew Morton authored
drivers/video/sis/sis_main.c: In function `sisfb_compat_ioctl': drivers/video/sis/sis_main.c:2204: warning: implicit declaration of function `lock_kernel' Signed-off-by:
-
Andrew Morton authored
Fix some confusion over fbdev compat_ioctl return types - compat_ioctls return `long'. Signed-off-by:
-
Antonino Daplas authored
Add (partial) support for 915G No HW cursor at the moment Screen is blanked but signal/sync is not switched off Mostly derived from XFree86/Xorg driver Pass "vesa_modes" and VESA_MODEDB_SIZE in call to "fb_find_mode()" to allow loading as module. Makes "vesa_modes" also the default "modedb" when linking statically into the kernel. Change PREFERRED_MODE to more reasonable value "1024x768-32@70" Signed-off-by:
Axel Buttchereit <XL@XLsigned.net> Signed-off-by:
-
lucasvr@gobolinux.org authored
This patch just fixes some typos and adds retval documentation for some functions that were missing it. I've also a question here: skeletonfb says that xxxfb_setcolreg() should return a negative errno on error. However, if the register number being accessed is out of bounds, 1 is returned. Shouldn't it be better to return -EINVAL instead? By looking at fbcmap.c, the retval isn't being checked against positive/negative values, so it doesn't make sense to return 1. Signed-off-by:
-
Antonino Daplas authored
Here's a patch that makes sure the return value of copy_from/to_user gets checked and handled in drivers/video/kyro/fbdev.c It also updates a comment at the top of the file that lists the files name and location. Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
-
Antonino Daplas authored
w100fb bugfix: The blanking function used vmalloc/vfree which isn't interrupt safe. To avoid problems, switch to kmalloc/kfree and use several buffers to avoid kmalloc size limitations. Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Antonino Daplas authored
FBIO_RADEON_SET_MIRROR always returns with -EINVAL even if successful due to an inappropriate fall-through. Signed-off-by:
Andreas Schwab <schwab@suse.de> Signed-off-by:
-
Alan Cox authored
Another first pass rescue run. Fix up for modern locking, make it build and check over. It could still do with other fixes (sleep_on etc) but it's a start Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Paul Jackson authored
Make CONFIG_CPUSETS enabled by default in sn2_defconfig. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Paul Jackson authored
This my cpuset patch, with the following changes in the last two weeks: 1) Updated to 2.6.8.1-mm1 2) [Simon Derr <Simon.Derr@bull.net>] Fix new cpuset to begin empty, not copied from parent. Needed to avoid breaking exclusive property. 3) [Dinakar Guniguntala <dino@in.ibm.com>] Finish initializing top cpuset from cpu_possible_map after smp_init() called. 4) [Paul Jackson <pj@sgi.com>] Check on each call to __alloc_pages() if the current tasks cpuset mems_allowed has changed. Use a cpuset generation number, bumped on any cpuset memory placement change, to make this check efficient. Update the tasks mems_allowed from its cpuset, if the cpuset has changed. 5) [Paul Jackson <pj@sgi.com>] If a task is moved to another cpuset, then update its cpus_allowed, using set_cpus_allowed(). 6) [Paul Jackson <pj@sgi.com>] Update Documentation/cpusets.txt to reflect above changes (4) and (5). I continue to recommend the following patch for inclusion in your 2.6.9-*mm series, when that opens. It provides an important facility for high performance computing on large systems. Simon Derr of Bull (France) and myself are the primary authors. Erich Focht has indicated that NEC is also a potential user of this patch on the TX-7 NUMA machines, and that he "would very much welcome the inclusion of cpusets." I offer this update to lkml, in order to invite continued feedback. The one prerequiste patch for this cpuset patch was just posted before this one. That was a patch to provide a new bitmap list format, of which cpusets is the first user. This patch has been built on top of 2.6.8.1-mm1, for the arch's: i386 x86_64 sparc ia64 powerpc-405 powerpc-750 sparc64 with and without CONFIG_CPUSET. It has been booted and tested on ia64 (sn2_defconfig, SN2 hardware). The 'alpha' arch also built, except for what seems to be an unrelated toolchain problem (crosstool ld sigsegv) in the final link step. === Cpusets provide a mechanism for assigning a set of CPUs and Memory Nodes to a set of tasks. Cpusets constrain the CPU and Memory placement of tasks to only the processor and memory resources within a tasks current cpuset. They form a nested hierarchy visible in a virtual file system. These are the essential hooks, beyond what is already present, required to manage dynamic job placement on large systems. Cpusets require small kernel hooks in init, exit, fork, mempolicy, sched_setaffinity, page_alloc and vmscan. And they require a "struct cpuset" pointer, a cpuset_mems_generation, and a "mems_allowed" nodemask_t (to go along with the "cpus_allowed" cpumask_t that's already there) in each task struct. These hooks: 1) establish and propagate cpusets, 2) enforce CPU placement in sched_setaffinity, 3) enforce Memory placement in mbind and sys_set_mempolicy, 4) restrict page allocation and scanning to mems_allowed, and 5) restrict migration and set_cpus_allowed to cpus_allowed. The other required hook, restricting task scheduling to CPUs in a tasks cpus_allowed mask, is already present. Cpusets extend the usefulness of, the existing placement support that was added to Linux 2.6 kernels: sched_setaffinity() for CPU placement, and mbind() and set_mempolicy() for memory placement. On smaller or dedicated use systems, the existing calls are often sufficient. On larger NUMA systems, running more than one, performance critical, job, it is necessary to be able to manage jobs in their entirety. This includes providing a job with exclusive CPU and memory that no other job can use, and being able to list all tasks currently in a cpuset. A given job running within a cpuset, would likely use the existing placement calls to manage its CPU and memory placement in more detail. Cpusets are named, nested sets of CPUs and Memory Nodes. Each cpuset is represented by a directory in the cpuset virtual file system, normally mounted at /dev/cpuset. Each cpuset directory provides the following files, which can be read and written: cpus: List of CPUs allowed to tasks in that cpuset. mems: List of Memory Nodes allowed to tasks in that cpuset. tasks: List of pid's of tasks in that cpuset. cpu_exclusive: Flag (0 or 1) - if set, cpuset has exclusive use of its CPUs (no sibling or cousin cpuset may overlap CPUs). mem_exclusive: Flag (0 or 1) - if set, cpuset has exclusive use of its Memory Nodes (no sibling or cousin may overlap). notify_on_release: Flag (0 or 1) - if set, then /sbin/cpuset_release_agent will be invoked, with the name (/dev/cpuset relative path) of that cpuset in argv[1], when the last user of it (task or child cpuset) goes away. This supports automatic cleanup of abandoned cpusets. In addition one new filetype is added to the /proc file system: /proc/<pid>/cpuset: For each task (pid), list its cpuset path, relative to the root of the cpuset file system. This file is read-only. New cpusets are created using 'mkdir' (at the shell or in C). Old ones are removed using 'rmdir'. The above files are accessed using read(2) and write(2) system calls, or shell commands such as 'cat' and 'echo'. The CPUs and Memory Nodes in a given cpuset are always a subset of its parent. The root cpuset has all possible CPUs and Memory Nodes in the system. A cpuset may be exclusive (cpu or memory) only if its parent is similarly exclusive. See further Documentation/cpusets.txt, at the top of the following patch. /proc interface: It is useful, when learning and making new uses of cpusets and placement to be able to see what are the current value of a tasks cpus_allowed and mems_allowed, which are the actual placement used by the kernel scheduler and memory allocator. The cpus_allowed and mems_allowed values are needed by user space apps that are micromanaging placement, such as when moving an app to a obtained by that app within its cpuset using sched_setaffinity, mbind and set_mempolicy. The cpus_allowed value is also available via the sched_getaffinity system call. But since the entire rest of the cpuset API, including the display of mems_allowed added here, is via an ascii style presentation in /proc and /dev/cpuset, it is worth the extra couple lines of code to display cpus_allowed in the same way. This patch adds the display of these two fields to the 'status' file in the /proc/<pid> directory of each task. The fields are only added if CONFIG_CPUSETS is enabled (which is also needed to define the mems_allowed field of each task). The new output lines look like: $ tail -2 /proc/1/status Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff Mems_allowed: ffffffff,ffffffff Signed-off-by:Dinakar Guniguntala <dino@in.ibm.com> Signed-off-by:
Simon Derr <simon.derr@bull.net> Signed-off-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Paul Jackson authored
[This is a copy of the bitmap list format patch that I submitted to lkml on 9 Aug 2004, after removing the prefix character fluff^Wstuff. I include it here again just to get it associated with the current cpuset patch, which will follow in a second email 10 seconds later. -pj] A bitmap print and parse format that provides lists of ranges of numbers, to be first used for by cpusets (next patch). Cpusets provide a way to manage subsets of CPUs and Memory Nodes for scheduling and memory placement, via a new virtual file system, usually mounted at /dev/cpuset. Manipulation of cpusets can be done directly via this file system, from the shell. However, manipulating 512 bit cpumasks or 256 bit nodemasks (which will get bigger) via hex mask strings is painful for humans. The intention is to provide a format for the cpu and memory mask files in /dev/cpusets that will stand the test of time. This format is supported by a couple of new lib/bitmap.c routines, for printing and parsing these strings. Wrappers for cpumask and nodemask are provided. Signed-off-by:
-
