Re: Larger dev_t
[EMAIL PROTECTED] wrote: > > OK - everybody back from San Jose - pity I couldnt come - > and it is no longer April 1st, so we can continue quarreling > a little. > > Interesting that where I had divided stuff in the trivial part, > the interesting part and the lot-of-work part we already start > fighting on the trivial part. Maybe it is not very important - > still I'd prefer to do things right from the start. > > Yes. We need a larger dev_t as everybody agrees. > How large? > > What is dev_t used for? It is a communication channel from > filesystem to user space (via the stat() system call) > and from user space to filesystem (via the mknod() system call). > > So, it seems the kernel interface must allow passing the values > that actually occur, in present or future file systems. > Making the interface narrow is only asking for problems later. > Are there already any filesystems that use 64-bits? > I would say that that is irrelevant - what we don't have today > may come tomorrow - but in fact the NFSv3 interface uses > a 64-bit device number. > > So glibc comes with 64 bits, the kernel has to hand these bits > over to NFS but is unwilling to - you are not going to get > more than 32. Why? > > > I have a holy crusade. > > I fail to see the connection. There is no bloat here, the kernel > is hardly involved. Some values are passed. If the values are > larger than the filesystem likes it will probably return EINVAL. > But the kernel has no business getting in the way. > > There is no matter of efficiency either - mknod is not precisely > the most frequently used system call, and our stat interface, which > really is important, is 64 bits today. I think the only reason for Linux to take 12 bit major is the fact that then he only has to increas the lenght of the static major device pointers in the kernel and it will be there... However the problem is mostly that the aforementioned array of pointers shouldn't me there in first place. > > Not using 64 also gives interesting small problems with Solaris or > FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20 > we cannot handle Solaris' majors and we cannot handle FreeBSD's minors. > > [Then there were discussions about naming. > These are interesting, but independent. > The current discussion is almost entirely about mknod.] > > Andries > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox wrote: > > > So change them as well for a new distribution. What's there problem. > > There isn't anything out there you can't do by hand. > > Fortunately so! > > So users cannot go back and forward between new and old kernels. Very good. > Try explaining that to serious production -users- of a system and see how > it goes down If anything I'm a *SERIOUS* production user. And I wouldn't allow *ANYBODY* here to run am explicitly tagged as developement kernel here anyway in an production enviornment. That's what releases are for damn. Or do you think that Linux should still preserve DOS compatibility in to the eternity as other "popular" systems do? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox wrote: > > > If anything I'm a *SERIOUS* production user. And I wouldn't allow > > *ANYBODY* here to run am explicitly tagged as developement kernel > > here anyway in an production enviornment. That's what releases are for > > damn. > > Or do you think that Linux should still preserve DOS compatibility > > in to the eternity as other "popular" systems do? > > You still break 2.4-2.6. Thats a production release jump. Right now I can > and do run 2.0->2.4 on the same box. If you dont understand why to many > people that is a requirement please talk to folks who run real business on > Linux You have possible no imagination about how real the business is I do :-). What's worth it to be able running 2.0 and 2.4 on the same box? I just intendid to tell you that there are actually people in the REAL BUSINESS out there who know about and are willing to sacifier compatibility until perpetuum for contignouus developement. BTW we don't run much of Cyrix486 hardware anymore here.. More like boxes with few gigs of ram 4 CPU's RAID and so on... The single biggest memmory hog here is currently the Oracle 9i AS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
> One thing I certainly miss: DevFS is not mandatory (yet). That's "only" due to the fact that DevFS is an insanely racy and instable piece of CRAP. I'm unhappy it's there anyway... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH tinny confusion cleanup in 2.4.3
Hello!
The attached patch remove the get_hardblock_size() function entierly
from the kernel. This is due to the fact that this function is
compleatly
unneccessary due to the existance of get_hardsect_size(), which got
introduced to properly encapsulate acesses to the hardsec_size[].
As a side effect this is reducing the number of module call-entrypoints
by one, which is a Good Thing TM.
Plase just apply it...
diff -urN linux/fs/buffer.c linux-new/fs/buffer.c
--- linux/fs/buffer.c Wed Apr 18 20:41:16 2001
+++ linux-new/fs/buffer.c Wed Apr 18 18:28:52 2001
@@ -555,25 +555,6 @@
return bh;
}
-unsigned int get_hardblocksize(kdev_t dev)
-{
- /*
-* Get the hard sector size for the given device. If we don't know
-* what it is, return 0.
-*/
- if (hardsect_size[MAJOR(dev)] != NULL) {
- int blksize = hardsect_size[MAJOR(dev)][MINOR(dev)];
- if (blksize != 0)
- return blksize;
- }
-
- /*
-* We don't know what the hardware sector size for this device is.
-* Return 0 indicating that we don't know.
-*/
- return 0;
-}
-
void buffer_insert_inode_queue(struct buffer_head *bh, struct inode *inode)
{
spin_lock(&lru_list_lock);
diff -urN linux/fs/ext2/super.c linux-new/fs/ext2/super.c
--- linux/fs/ext2/super.c Fri Dec 29 23:36:44 2000
+++ linux-new/fs/ext2/super.c Wed Apr 18 19:19:44 2001
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
@@ -404,11 +405,9 @@
* This is important for devices that have a hardware
* sectorsize that is larger than the default.
*/
- blocksize = get_hardblocksize(dev);
- if( blocksize == 0 || blocksize < BLOCK_SIZE )
- {
+ blocksize = get_hardsect_size(dev);
+ if(blocksize < BLOCK_SIZE )
blocksize = BLOCK_SIZE;
- }
sb->u.ext2_sb.s_mount_opt = 0;
if (!parse_options ((char *) data, &sb_block, &resuid, &resgid,
@@ -482,11 +481,9 @@
* Make sure the blocksize for the filesystem is larger
* than the hardware sectorsize for the machine.
*/
- hblock = get_hardblocksize(dev);
- if((hblock != 0)
- && (sb->s_blocksize < hblock) )
- {
- printk("EXT2-fs: blocksize too small for device.\n");
+ hblock = get_hardsect_size(dev);
+ if (sb->s_blocksize < hblock) {
+ printk(KERN_ERR "EXT2-fs: blocksize too small for device.\n");
goto failed_mount;
}
diff -urN linux/fs/isofs/inode.c linux-new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c Wed Apr 18 20:41:16 2001
+++ linux-new/fs/isofs/inode.c Wed Apr 18 20:23:40 2001
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -493,21 +494,21 @@
printk("iocharset = %s\n", opt.iocharset);
#endif
- /*
-* First of all, get the hardware blocksize for this device.
-* If we don't know what it is, or the hardware blocksize is
-* larger than the blocksize the user specified, then use
-* that value.
-*/
- blocksize = get_hardblocksize(dev);
- if(blocksize > opt.blocksize) {
- /*
-* Force the blocksize we are going to use to be the
-* hardware blocksize.
-*/
- opt.blocksize = blocksize;
+ /*
+* First of all, get the hardware blocksize for this device.
+* If we don't know what it is, or the hardware blocksize is
+* larger than the blocksize the user specified, then use
+* that value.
+*/
+ blocksize = get_hardsect_size(dev);
+ if(blocksize > opt.blocksize) {
+ /*
+* Force the blocksize we are going to use to be the
+* hardware blocksize.
+*/
+ opt.blocksize = blocksize;
}
-
+
blocksize_bits = 0;
{
int i = opt.blocksize;
diff -urN linux/fs/minix/inode.c linux-new/fs/minix/inode.c
--- linux/fs/minix/inode.c Wed Apr 18 20:41:16 2001
+++ linux-new/fs/minix/inode.c Wed Apr 18 20:27:54 2001
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -179,7 +180,7 @@
const char * errmsg;
struct inode *root_inode;
unsigned int hblock;
-
+
/* N.B. These should be compile-time tests.
Unfortunately that is impossible. */
if (32 != sizeof (struct minix_inode))
@@ -187,8 +188,8 @@
if (64 != sizeof(struct minix2_inode))
panic("bad V2 i-node size");
- hblock = get_hardblocksize(dev);
- if (hblock && hblock > BLOCK_SIZE)
+ hblock = get_hardsect_size(dev);
+ if (hblock > BLOCK_SIZE)
goto out_bad_hblock;
set_blocksize(d
Re: [BUG] lvm beta7 and ac11 problems
Jens Axboe wrote: > > On Sat, Apr 21 2001, Ed Tomlinson wrote: > > Hi, > > > > building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields: > > > > oscar# depmod -ae 2.4.3-ac11 > > depmod: *** Unresolved symbols in >/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o > > depmod: get_hardblocksize > > > > ideas? > > s/get_hardblocksize/get_hardsect_size And don't forget to have a look whatever the get_hardblocksize == 0 check or similar can't be killed alltogether as well - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] lvm beta7 and ac11 problems
Jeff Chua wrote:
>
> On Mon, 23 Apr 2001, Martin Dalecki wrote:
>
> > > > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
>
> try this (after you have applied the patch for lvm 0.9.1_beta7) ...
>
> Jeff
> [[EMAIL PROTECTED]]
>
> --- /u2/src/linux/drivers/md/lvm.c.org Mon Apr 23 21:11:32 2001
> +++ /u2/src/linux/drivers/md/lvm.c Mon Apr 23 21:12:27 2001
> @@ -1791,7 +1791,7 @@
> int max_hardblocksize = 0, hardblocksize;
>
> for (le = 0; le < lv->lv_allocated_le; le++) {
> - hardblocksize =
> get_hardblocksize(lv->lv_current_pe[le].dev);
> + hardblocksize =
> get_hardsect_size(lv->lv_current_pe[le].dev);
^
> if (hardblocksize == 0)
> hardblocksize = 512;
^
Those above two code lines can be killed, since get_hardsect_size
is returning the default sector size of Linux (namely 512 bytes)
in case the driver didn't have a chance to set hardsect_size[] array
in time for usage (Which shouldn't happen anyway).
> if (hardblocksize > max_hardblocksize)
> @@ -1801,7 +1801,7 @@
> if (lv->lv_access & LV_SNAPSHOT) {
> for (e = 0; e < lv->lv_remap_end; e++) {
> hardblocksize =
> - get_hardblocksize(
> + get_hardsect_size(
>
> lv->lv_block_exception[e].rdev_new);
> if (hardblocksize == 0)
> hardblocksize = 512;
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device Major max and Disk Max in 2.4.x kernel
"Dupuis, Don" wrote:
>
> I have already sent a patch to Alan and Linus on this issue. Linus has
> never responed and Alan said he would look into it in the middle of April.
> Nothing is new at this point
>
> -Original Message-
> From: PhiloVivero [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 22, 2001 12:12 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Device Major max and Disk Max in 2.4.x kernel
>
> I have a problem. Trying to write an iostat for Linux (or use an existing
> one):
>
> >From the kernel source:
>
> [/usr/src/linux-2.4.2/include/linux] :) grep DK_MAX *.h
> kernel_stat.h:#define DK_MAX_MAJOR 16
> kernel_stat.h:#define DK_MAX_DISK 16
>
> What to notice: MAJOR and DISK max are 16.
>
> Again, from the kernel source:
>
> [/usr/src/linux-2.4.2/fs/proc] :) grep -15 DK_MAX proc_misc.c
>
> for (major = 0; major < DK_MAX_MAJOR; major++) {
> for (disk = 0; disk < DK_MAX_DISK; disk++) {
> int active = kstat.dk_drive[major][disk] +
> kstat.dk_drive_rblk[major][disk] +
> kstat.dk_drive_wblk[major][disk];
> if (active)
> len += sprintf(page + len,
> "(%u,%u):(%u,%u,%u,%u,%u) ",
> major, disk,
> kstat.dk_drive[major][disk],
> kstat.dk_drive_rio[major][disk],
> kstat.dk_drive_rblk[major][disk],
> kstat.dk_drive_wio[major][disk],
> kstat.dk_drive_wblk[major][disk]
> );
> }
> }
>
> What to notice: We are looping up to the DK_MAX_MAJOR and DK_MAX_DISK. What
> this means is, any major >16 or disk >16 won't be listed in /proc/stat under
> the "disk_io" section.
>
> Problem. On my system, which I figure is not too uncommon, I have several
> partitions on two hard drives and a CDROM. They are configured thusly:
>
> # cat /proc/partitions
> major minor #blocks name
>3 0 20094480 hda
>3 16313513 hda1
>3 2 401625 hda2
>3 3 13374112 hda3
>3644497152 hdb
> 56 0 45034920 hdi
> 56 1 22490968 hdi1
> 56 2 22539195 hdi2
>
> What to notice: I have a drive on /dev/hdi (never mind why, it actually
> works)
> that is block major 56. Not only that, my cdrom device on /dev/hdb is block
> major 3, but minor number 64. I am assuming for disks, minor == disk. Sorry
> if
> this is an incorrect assumption.
>
> No stats for /dev/hdi nor /dev/hdb ever show up in /proc/stat. Only for
> /dev/hda. On my other 2.4.2 system, with multiple hard drives under 16/16,
> I get multiple devices under /proc/stat.
>
> The patch seems relatively easy. Change linux/include/linux/kernel_stat.h to
> allow block major up to 56 (in my case... 64 in general???) and disks up to
> 64
> (in my case).
>
> But we might need more than 64 disks on a block major (there are MANY snips
> in
> this so-called cut 'n' paste, because I figure you don't want to see them
> all):
>
> # l /dev/hd* | sort -n
> brw-rw1 root disk 3, 79 Feb 22 08:57 /dev/hdb15
> brw-rw1 root disk 3, 80 Feb 22 08:57 /dev/hdb16
> brw-rw1 root disk 22, 79 Feb 22 08:57 /dev/hdd15
> brw-rw1 root disk 22, 80 Feb 22 08:57 /dev/hdd16
> brw-rw1 root disk 33, 79 Feb 22 08:57 /dev/hdf15
> brw-rw1 root disk 33, 80 Feb 22 08:57 /dev/hdf16
> brw-rw1 root disk 34, 79 Feb 22 08:57 /dev/hdh15
> brw-rw1 root disk 34, 80 Feb 22 08:57 /dev/hdh16
> brw-rw1 root disk 56, 126 Mar 25 17:14 /dev/hdj62
> brw-rw1 root disk 56, 127 Mar 25 17:14 /dev/hdj63
>
> What to notice: We have disks up to 127. I never see any block major over 64
> on my system. The /dev/hdj device isn't used on my system. /dev/hdi and
> /dev/hdj belong to a Promise RAID controller on a new-ish
> ASUS AMD motherboard.
>
> Let me know if I can be of further service. I must bashfully admit that I'm
> not enough of a guru to recompile my kernel anymore, or I'd tweak the
> kernel_stat.h file and recompile myself to test this.
>
> This is just hazy recollection, but I think the 2.2.x kernels have the same
> problem.
Just never thing about those stats - they just broken by design.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
Tim Jansen wrote: > > The Linux Device Registry (devreg) is a kernel patch that adds a device > database in XML format to the /proc filesystem. It collects all information OH SHIT!! ^^^ Why don't you just add postscript output to /proc? > about the system's physical devices, creates persistent device ids and > provides them in the file /proc/devreg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
Tim Jansen wrote: > > On Tuesday 24 April 2001 11:40, Martin Dalecki wrote: > > Tim Jansen wrote: > > > The Linux Device Registry (devreg) is a kernel patch that adds a device > > > database in XML format to the /proc filesystem. It collects all > > OH SHIT!! ^^^ > > Why don't you just add postscript output to /proc? > > XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, > I gave this up after trying to fit the complex USB > configuration/interface/endpoint data into name/value pairs. Thinking about > text file formats that allow me to display hierarchical information, XML was > the obvious choice for me. Are there alternatives to get complex and > extendable information out to user space? (see > http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg > output) Yes filesystem structures. Or just simple parsing in the user space plain binary data. > My other ideas were: > - using a simple binary format, just dump structs. This would break all > applications every time somebody changes the format, and this should happen > very often because of the nature of the format > - using a complicated, extendable binary format, for example chunk-based like > (a|r)iff file formats. This would add more code in the kernel than XML > output, is difficult to understand and requires more work in user space > (because XML parsers are already available) > - making up a new text-based format with properties similar to XML because I > knew that many people dont like the idea of XML output in the kernel.. I > really thought about it, but it does not make much sense. > > The actual code overhead of XML output compared to a format like > /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. > I agree that XML is not perfect for this kind of data, but it is simple to > generate, well known and I dont see a better alternative. > > bye.. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
Peter Samuelson wrote: > > [BERECZ Szabolcs] > > Here is a new syscall. With this you can change the owner of a running > > procces. > > > + if (current->euid) > > + return -EPERM; > > Use capable(). > > > + p = find_task_by_pid(pid); > > + p->fsuid = p->euid = p->suid = p->uid = uid; > > Race -- you need to make sure the task_struct doesn't disappear out > from under you. > > Anyway, why not use the interface 'chown uid /proc/pid'? No new > syscall, no arch-dependent part, no user-space tool, etc. Becouse of exactly the same race condition as above maybe? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI id list update
Just a small trivial obviously correct update... diff -ur linux/include/linux/pci_ids.h linux-mega/include/linux/pci_ids.h --- linux/include/linux/pci_ids.h Tue Nov 21 16:31:52 2000 +++ linux-mega/include/linux/pci_ids.h Tue Nov 21 18:54:58 2000 @@ -257,6 +257,11 @@ #define PCI_VENDOR_ID_WD 0x101c #define PCI_DEVICE_ID_WD_7197 0x3296 +#define PCI_VENDOR_ID_AMI 0x101E +#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010 +#define PCI_DEVICE_ID_AMI_MEGARAID20x9060 +#define PCI_DEVICE_ID_AMI_MEGARAID30x1960 + #define PCI_VENDOR_ID_AMD 0x1022 #define PCI_DEVICE_ID_AMD_LANCE0x2000 #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001 @@ -365,8 +370,8 @@ #define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010 #define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020 -#define PCI_VENDOR_ID_DPT 0x1044 -#define PCI_DEVICE_ID_DPT 0xa400 +#define PCI_VENDOR_ID_DPT 0x1044 +#define PCI_DEVICE_ID_DPT 0xa400 #define PCI_VENDOR_ID_OPTI 0x1045 #define PCI_DEVICE_ID_OPTI_92C178 0xc178 @@ -1210,6 +1215,7 @@ #define PCI_DEVICE_ID_INTEL_82441 0x1237 #define PCI_DEVICE_ID_INTEL_82380FB0x124b #define PCI_DEVICE_ID_INTEL_82439 0x1250 +#define PCI_DEVICE_ID_INTEL_80960_RP 0x1960 #define PCI_DEVICE_ID_INTEL_82371SB_0 0x7000 #define PCI_DEVICE_ID_INTEL_82371SB_1 0x7010 #define PCI_DEVICE_ID_INTEL_82371SB_2 0x7020
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: > > On Tue, 5 Sep 2000, Alexander Viro wrote: > > > > > > What would be acceptable is something that understands C, and that can be > > > used to follow these things. Like "tags". > > > > I don't like hungarian notation too, but tags is out of question, > > unfortunately. Too much preprocessor abuse in include/*/*.h. > > Notice the _like_ tags. > > Basically, what I'm saying is that I understand why people want to grep > for specific uses, but I'm saying that a pure textual greap that doesn't > understand the context is not an option - because it implies adding > "cruft" to everything you want to grep for. Not for readability, but for > greppability. > > And I'm saying that if people really want to do this, then use the > computer to do it for you, having more than just "grep", and making your > tools aware of it. There is some facility allowing to implement this kind of things in the C++ part of the most recent EGCS version which makes implementing such things "relatively" easy - basiclly there is the provision to dump the parser trees as easy to process ascii text already there. Basically I think this dererr of syntactical analysis can only be implementen by serious help from the compiler. Maybe this is a new argument to facilitate at least correct syntactical processing of the kernel by the C++ flavour of EGCS? Please note that this wouldn't need to generate really executable code - which as we all know is rather difficult due to the extensive runtime support as well as ehm. the wired calling conventions C++ is oppressing on the compiler... Just correct syntactical processing is all what's neccessary - this isn't THAT difficult to achive ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > There is some facility allowing to implement this kind of things > > in the C++ part of the most recent EGCS version which makes implementing > > such things "relatively" easy - basiclly there is the provision to dump > > the parser trees as easy to process ascii text already there. > > Fuck C++, by what bloody magic are you going to account for cpp? Easy - the same way you do for cross compilation. Basically just: export CC=g++ --some-magic-long-option-i-dont-remember; make And then the normal compilation is not just generating *.o files, but files with dumped parser trees as well. Hell It's even documented there! > > Maybe this is a new argument to facilitate at least correct syntactical > > processing of the kernel by the C++ flavour of EGCS? > > No, it would not. If g++ can do that, gcc also should be able to, No - becouse we basically write C++ compatible C code but in fact the compiler is allowed to have much tighter assumptions about the type system under C++ then it is under C, so it has *MORE* valuable data at hand... > especially by the time when we will have preprocessor BS under control in > sufficient degree. Right now neither gcc nor g++ will see the large part > of tree. Basically I will just guess: The next maybe non free version of source navigator will use the mechanism I have just described above. So maybe there is already someone at RedHat doing exactly this work already ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Remarks about sigtestsetmask()
1. This function is only used in the poorly maintained ftape driver. The usage there isn't appriopriate for modern kernels. 2. This function acts only on the sig set of the current process, so the first parameter should be just a porinter to current, instead of currgen->sigset. So it should be presumably removed all-together. -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > Easy - the same way you do for cross compilation. Basically just: > > > > export CC=g++ --some-magic-long-option-i-dont-remember; make > > ... and you still have only a subset of the tree, simply because it is fed > through cpp before it reaches the parser. And cpp cuts away many pieces. > Different config options and you've got a different subset. Good luck > providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) > > Basically I will just guess: The next maybe non free version of > > source navigator will use the mechanism I have just described above. > > So maybe there is already someone at RedHat doing exactly this work > > already ;-). > > Physically impossible without a major cleanup of the tree. Yeah... let me be nice to you as well Source Navigator got released for free - since the project died inside RedHat anyway due to the fact that it's full of the worst coding practices I ever saw - like for example literally copy and paste Tcl/Tk/iTcl and such. So instead of buring it they just threw it "out of the window" for "free". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Remarks about sigtestsetmask()
Alan Cox wrote: > > > 1. This function is only used in the poorly maintained ftape driver. > >The usage there isn't appriopriate for modern kernels. > > The ftape driver isnt exactly poorly maintained. Its just not integrated into > 2.3/2.4. Ftape 4.0 is still elsewhere This is wrong, since last time I checked the maintainer stepped back from the tast. And I understand reintegration into the mainstream kernel proper maintainance as well. (The two versions are *VERY* different). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > > We could use some more infrastructure here. > > > > (1) A 'make randomconfig' tool that generates a random configuration. > > > > (2) Make the architecture a configuration variable (!) > > > > (3) A collection of RPM's so that people can download and install > > all the cross tools easily. > > (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of > source files being compiled. > > Providing better tools is nice, but simplifying the problem domain > sometimes pays better... So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > So may I just suggest to repleace the usage of cpp at all with something > > more > > suitable for the task at hand and with a much more regular/stringent > > syntax > > better fitting into the syntax of the pure C language like m4 for > > example? > > > > No. Still "better tools" variant. Check blk_dev_init() and tell me how do > you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. > how many of these CONFIG_... are needed anywhere on C level. Hint: see > module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. > > The main problem with the CONFIG_ blah's isn't either the syntax nor > > they current usage - the problem is inherent to the simple fact > > that the number of possible combinations is of a very high order due > > to simple combinatorics. > > It's not a fact, it's a problem... It doesn't _have_ to be very high > order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells wrote: > > I've done an implementation of some of the Win32 "system calls" in a kernel > module in an attempt to speed up Wine. Please by no way don't include this patch into the official tree. It's insane due to the following: 1. Linux is UNIX not NT... (in terms of API) 2. WINE in itself is barely usefull - even in fact non existant, since there is no official stable release out there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Simon Richter wrote: > > On Thu, 7 Sep 2000, Martin Dalecki wrote: > > > > I've done an implementation of some of the Win32 "system calls" in a kernel > > > module in an attempt to speed up Wine. > > > 1. Linux is UNIX not NT... (in terms of API) > > What about a Win32 personality? > > > 2. WINE in itself is barely usefull - even in fact non existant, since > > there is > >no official stable release out there. > > Erm, ever seen Adobe Photopaint for Linux? It's basically the Windows .exe > plus a wine that can do all the syscalls Photopaint needs. Yes seen. Huge bloadted instabile piece of hack on top of a hack on top of a hack... If I need NT I can use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
Gary Lawrence Murphy wrote: > The analogy to typing hex codes or toggling code at the console is > also apt. Unix ascended over Multix in no small part because of C, > which drew sneers from the trad programmer of the day. Personally, I > tend to debug intuitively based on my knowledge of code, but not > exclusively. In my 25 years in this business, I have seen amazing > things done with debuggers, things that had stumped whole teams of > very good programmers. Intuition still plays a vital role, but gdb in > the right hands can prove things that would take months of code > tweaking to do by hand. Maybe it's that just 25 years in this industry made you for Alzheimer, since you should know that the first versions of UNIX where actually written in plain assembler. So C certainly isn't what made for it's success in first place. And then please just compare C with any other modern programming language like pascal/modula/java/C++/objective/C/ADA or anything elese. From all of them C is the most "assembler alike" language and still the most widely used for OS programming out there: BeOS, NT, UNIX, QNX, VMS, CP/M, DOS, Mach, and so on and so on. Second: GDB is DREADFULL in terms of user friendliness... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Chris Evans wrote: > > On Tue, 12 Sep 2000, Hans Reiser wrote: > > > I really think Rik has it right here. In particular, an MP3 player > > needs to be able to say, I have X milliseconds of buffer so make my > > worst case latency X milliseconds. The number of requests is the > > wrong metric, because the time required per request depends on disk > > geometry, disk caching, etc. > > Hi, > > We need to separate "what's a good idea" from "what's the best way to do > it". > > Sure, it's a good idea to get an mp3 player's I/O request serviced within > a certain amount of time. Is the best way to do that hacking the concept > of time into the elevator algorithm? That's currently under debate. > > In fact, the guarantee of I/O service time for a single process (mp3 > player) is pretty orthogonal to the per-device elevator settings. If you > have a certain block device set to a max latency of 0.25s, and lots of > processes are hammering the disk, then something will have to give, > i.e. under heavy load this setting will be useless and not honoured. > > The solution to this particular mp3 player scenario would be something > like the task scheduler policies we have. For example, maybe we could flag > a given process so that all it's I/O requests go to the head of the queue. > > Cheers > Chris First of all: In the case of the mp3 player and such there is already a fine proper way to give it better chances on getting it's job done smooth - RT kernel sceduler priorities and proper IO buffering. I did something similiar to a GDI printer driver... Second: The concept of time can give you very very nasty behaviour in even cases. Assume that a disc can only do 1 request per second. And then imagin a sceduling based on a 1+epsilon second... basically the disc will be run with half the speed it could. Those nasty integer arithmetics can you catch easly and mostly allways entierly unexpecting. Third: All you try to improve is the boundary case between an entierly overloaded system and a system which has a huge reserve to get the task done. I don't think you can find any "improvement" which will not just improve some cases and hurt some only slightly different cases badly. That's basically the same problem as with the paging strategy to follow. (However we have some kind of "common sense" in respect of this, despite the fact that linux does ignore it...) Firth: The most common solution for such boundary cases is some notion of cost optimization, like the nice value of a process or page age for example, or alternative some kind of choice between entierly different strategies (remember the term strategy routine) - all of them are just *relative* measures not absolute time constrains. Fifth: I think that such kind of IO behaviour control isn't something generic enough for the elevator - it should be all done on the device driver level, if at all. In fact you have already bad interactions between strategies of low level drivers and the high level code in Linux - like for example the "get from top of queue" or "don't get it from top of the IO queue" mess between IDE and SCSI middlelayers... (However this got a bit better recently.) -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Andrea Arcangeli wrote: > > On Tue, 12 Sep 2000, Martin Dalecki wrote: > > >First of all: In the case of the mp3 player and such there is already a > >fine > >proper way to give it better chances on getting it's job done smooth - > >RT kernel sceduler priorities and proper IO buffering. I did something > >similiar > >to a GDI printer driver... > > Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger > than 128mbyte :) and then run in background `cp /dev/zero .` in the same > fs where your mp3 file out of cache is living. Then you'll see why a large > buffer is useless if there's none kind of I/O fair scheduling into the > elevator. Repeat the same test in 2.2.16 then. > > The I/O latency Hans was taking about for the mp3 player, is the time it > takes for the buffer to become empty. I was talking about *proper* buffering not necessary *big* buffers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: > lessons learned in live customer accounts. In NetWare, requests are > merged at A) the boundry between the File Cache and the I/O subsystem, > and B) in the drivers themselves and NOT THE ELEVATOR. Yes that's the proper place to do this. The generic elevator on a *single* queue makes not much sense. Once ago I have just disabled it entierly and on a system with swap on a separate disk and controller this was a performance *win*. Some of the FS code in esp. the ISO9660 does even under linux something *very* much like this. Many of the prop. cd-rom device drivers are basically emulating 512k block devices by reading ahead and throwing away data. There is really plenty of room for improvement here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Hans Reiser wrote: > > I really think Rik has it right here. In particular, an MP3 player needs to be able >to say, I have > X milliseconds of buffer so make my worst case latency X milliseconds. The number >of requests is > the wrong metric, because the time required per request depends on disk geometry, >disk caching, etc. > No the problem is that an application should either: 1. Take full controll of the underlying system. 2. Don't care about selftuning the OS. Becouse that's what operating systems are for in first place: Letting the applications run without care of the underlying hardware. Linux is just mistaken by desing that there should be a generic elevator for any block device sitting on a single queue for any kind of attached device. Only device drivers know best how to handle queueing and stuff like this. The upper layers should only car about semanticall correctness of the request orders not about optimization of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: > > Martin, > > I'm glad you are not still mad at me. :-) I hope this info was > helpful. Yes it was in fact this one of the more interresting posts in this thread. Thanks for the excellent reading. (However much of it sounded very familiar... maybe they learned the same lessons at Sun or Berkeley? ;-) The most important fact is that there is no misconception of blocks like there is currently under Linux. Linux is basically using FOUR different block concepts in case of the block device handling: 1. Filesystem iduced blocks. 2. physical block size. 3. buffer block size. Where in fact there should be only two: 1. FS block 2. physical block size. Merging 2. and 3. should be handled on the driver level. Interrestingliy enough the driver writers do it "intuitively" very freqeuntly indeed (ATAPI cd or mcdx for example). However they get beaten by the fact that sometimes the dividing line even between 1. and 2. isn't clean unter linux ;-)... insead of just basing anything on a basic buffer block size like 512 bytes. Interrestingly there is the same overgranulation in the concept of read-ahead under linux: 1. VFS read write - ahead. 1b. FS specific read write ahead. 2. Driver read write -ahead. 3. Physical device cache read write -ahead. Once again at least one point too much and then you could see the elevator as even just 4. some kind of wired variable block write/read-ahead... In fact most of the read aheads above are just foo due to the fact that the one enumerated as 3. is aleviating them. However due to "code impedancy", in esp. driver code impedancy I doubt seriously this will get ever cleaned up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
Andrea Arcangeli wrote: > > On Wed, 13 Sep 2000, Martin Dalecki wrote: > > >"Jeff V. Merkey" wrote: > > > >> lessons learned in live customer accounts. In NetWare, requests are > >> merged at A) the boundry between the File Cache and the I/O subsystem, > >> and B) in the drivers themselves and NOT THE ELEVATOR. > > > >Yes that's the proper place to do this. The generic elevator on a > > Jens is taking care of A) using kiobufs. We can't achieve A right now > because the I/O entity is 4k sized at max. That limitation is well known > and it cames from the old days and it's not a trivial one to address. It's > not a VM page-cache limitation but a blkdev API one. I agree it's silly to > split the big chunks in little bh and then re-merge them in one single > request later as we have to do. > > >*single* queue > >makes not much sense. Once ago I have just disabled it entierly and on a > > About B) I can' believe you seriously want to duplicate the merging code > in each lowlevel driver given most of them could share the same code (as > they're doing in linux). Yes seriously I would like to see it duplicated there. Becouse on this level it would be *far* simpler then on the generic level. And for a noabnormal configuration I guess the overall code size would be smaller then the generic aproach. Typically you just don't have that many *different* devices in your system: Either IDE or SCSI that's all. (OK that's just guessing...) > For the special ones you can just now use your own lowlevel driver > elevator/mergingcode/queuelength by intializing the callbacks > appropriately during driver intialization (NOTE: this is a new feature in > 2.4.x!) Could you do me the favour and just tell me inside which struct they are exactly? I would love it to try an elimination of the generic code on my system at home ;-). > I guess Netware doesn't have 402789 lines of blockdevice device drivers so > probably not doing code sharing properly is less an issue there. This is > just a guess, I may be wrong (in this case you should correct me, thanks). > > andrea@athlon:~ > wc -l kernel/devel/2.4.0-test8/drivers/block/* >kernel/devel/2.4.0-test8/drivers/ide/* kernel/devel/2.4.0-test8/drivers/i2o/* >kernel/devel/2.4.0-test8/drivers/scsi/* >kernel/devel/2.4.0-test8/drivers/block/paride/* >kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx/* >kernel/devel/2.4.0-test8/drivers/scsi/pcmcia/*| tail -1 > wc: kernel/devel/2.4.0-test8/drivers/block/paride: Is a directory > wc: kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx: Is a directory > wc: kernel/devel/2.4.0-test8/drivers/scsi/pcmcia: Is a directory > 402789 total > > Andrea -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
Andi Kleen wrote: > > On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote: > > About B) I can' believe you seriously want to duplicate the merging code > > in each lowlevel driver given most of them could share the same code (as > > they're doing in linux). > > I guess it would just be a library call. e.g. the BSDs just have a disksort() > function that is called from the drivers as needed. For smart devices > with very intelligent firmware you simply do not call it (assuming you > have decently sized kiovec requests, with the current bh approach some > premerging is probably always needed) Yes - this is the cleanest solution in terms of code organization. You don't need to put it into a special struct and allways track it through pointer derefference - it's not a true callback in nature after all, since it doesn't need to be called asynchronously. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:John Byrne <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. And devfs doesn't provide NOTHING to facilitate it... -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proc fs limit workaround?
Ricky Beam wrote: > > On Thu, 14 Sep 2000, Nick Pollitt wrote: > ... > >And second, why is the 4K limit there in the first place? > > Primarily because it was never designed for 90% of the crap that's in there > now. I have long hated the BS required to get more than 4k worth of stuff > out of /proc. The way around the limit is not a solution, it's a hack. > There's not atomicy for processing more than one page unless you go out > of your way to deal with it. I've banged my head on the desk a few times > because of this -- what happens when there's any delay between read()'s? > *sigh* > > #ifdef RANT > In case you haven't noticed a lot of present-day linux is a nice collection > of hacks. This is the nature of code evilution -- I have to deal with this > everyday (of course, I'm paid to.) procfs was actually a Very Good Thing(r) > six or seven years ago when it was _designed_. Now look at it. > > I'm a perfectionist. I like things to be well planned, designed, and > emplimented to do what they were designed to do. If you want it to do > something else, return to the planning stage. For example, 747's weren't > designed to clear cut forests. While they can be used for such a task, > they are quite inefficient at it. > #endif I only disagree in one point - /proc was a bad design from the beginning on, since you could expect to get what you have now there (Actually please see in archives those MANY MANY people on linux-kernel who where arguing against it before it ever got in... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Andi Kleen wrote:
>
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual lies on that),
> e.g. the register allocation is usually worse and CSE doesn't work that well.
> Normally it makes not that much difference, but these macros are rather
> performance critical.
The GCC manual doesn't lie on that ANY LONGER with respect to EGCS.
And we should adpat for the modern versions of the compiler instead
of dragging the *ugly* code with us until the earth stops spinning, iff
the only concern is performance.
>
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> I would prefer to fix the callers anyways, because it is clearer this way.
>
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
- phone: +49 214 8656 283
- job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PATCH: killing read_ahead[]
Hello!
Please have a look at the following patch and feel free to be scared
by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
read_ahead[] array and during the whole past decade was!
If you really care about clean internal interfaces this should be
one of those prio number ONE targets to shoot at...
The most amanzing thing is that the whole test10-pre5 kernel with this
patch applied doesn't show any performance penalties for me at all!
And of corse it's about 10k smaller...
--mdcki
diff -ur linux-test10-pre5/arch/sparc64/kernel/ioctl32.c
linux/arch/sparc64/kernel/ioctl32.c
--- linux-test10-pre5/arch/sparc64/kernel/ioctl32.c Tue Oct 24 13:52:02 2000
+++ linux/arch/sparc64/kernel/ioctl32.c Tue Oct 24 15:37:56 2000
@@ -2136,7 +2136,7 @@
uint32_t lv_badblock;
uint32_t lv_allocation;
uint32_t lv_io_timeout;
- uint32_t lv_read_ahead;
+ uint32_t lv_NOT_USED;
/* delta to version 1 starts here */
u32 lv_snapshot_org;
u32 lv_snapshot_prev;
@@ -3100,7 +3100,6 @@
COMPATIBLE_IOCTL(BLKROGET)
COMPATIBLE_IOCTL(BLKRRPART)
COMPATIBLE_IOCTL(BLKFLSBUF)
-COMPATIBLE_IOCTL(BLKRASET)
COMPATIBLE_IOCTL(BLKFRASET)
COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
@@ -3621,7 +3620,6 @@
HANDLE_IOCTL(SIOCRTMSG, ret_einval)
HANDLE_IOCTL(SIOCGSTAMP, do_siocgstamp)
HANDLE_IOCTL(HDIO_GETGEO, hdio_getgeo)
-HANDLE_IOCTL(BLKRAGET, w_long)
HANDLE_IOCTL(BLKGETSIZE, w_long)
HANDLE_IOCTL(0x1260, broken_blkgetsize)
HANDLE_IOCTL(BLKFRAGET, w_long)
diff -ur linux-test10-pre5/drivers/acorn/block/mfmhd.c
linux/drivers/acorn/block/mfmhd.c
--- linux-test10-pre5/drivers/acorn/block/mfmhd.c Wed Oct 4 01:39:44 2000
+++ linux/drivers/acorn/block/mfmhd.c Tue Oct 24 15:35:40 2000
@@ -1231,8 +1231,6 @@
case BLKFLSBUF:
case BLKROSET:
case BLKROGET:
- case BLKRASET:
- case BLKRAGET:
case BLKPG:
return blk_ioctl(dev, cmd, arg);
@@ -1448,7 +1446,6 @@
hdc63463_irqpollmask= irqmask;
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB?) read ahread */
#ifndef MODULE
mfm_gendisk.next = gendisk_head;
diff -ur linux-test10-pre5/drivers/block/DAC960.c linux/drivers/block/DAC960.c
--- linux-test10-pre5/drivers/block/DAC960.cTue Oct 24 13:52:03 2000
+++ linux/drivers/block/DAC960.cTue Oct 24 15:24:51 2000
@@ -1931,10 +1931,7 @@
Controller->GenericDiskInfo.sizes = Controller->PartitionSizes;
blksize_size[MajorNumber] = Controller->BlockSizes;
max_sectors[MajorNumber] = Controller->MaxSectorsPerRequest;
- /*
-Initialize Read Ahead to 128 sectors.
- */
- read_ahead[MajorNumber] = 128;
+
/*
Complete initialization of the Generic Disk Information structure.
*/
@@ -4964,16 +4961,6 @@
return put_user(Controller->GenericDiskInfo.part[MINOR(Inode->i_rdev)]
.nr_sects,
(long *) Argument);
-case BLKRAGET:
- /* Get Read-Ahead. */
- if ((long *) Argument == NULL) return -EINVAL;
- return put_user(read_ahead[MAJOR(Inode->i_rdev)], (long *) Argument);
-case BLKRASET:
- /* Set Read-Ahead. */
- if (!capable(CAP_SYS_ADMIN)) return -EACCES;
- if (Argument > 256) return -EINVAL;
- read_ahead[MAJOR(Inode->i_rdev)] = Argument;
- return 0;
case BLKFLSBUF:
/* Flush Buffers. */
if (!capable(CAP_SYS_ADMIN)) return -EACCES;
diff -ur linux-test10-pre5/drivers/block/acsi.c linux/drivers/block/acsi.c
--- linux-test10-pre5/drivers/block/acsi.c Thu Feb 17 00:42:05 2000
+++ linux/drivers/block/acsi.c Tue Oct 24 15:24:13 2000
@@ -1792,9 +1792,8 @@
}
phys_acsi_buffer = virt_to_phys( acsi_buffer );
STramMask = ATARIHW_PRESENT(EXTD_DMA) ? 0x : 0xff00;
-
+
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read-ahead */
acsi_gendisk.next = gendisk_head;
gendisk_head = &acsi_gendisk;
diff -ur linux-test10-pre5/drivers/block/ataflop.c linux/drivers/block/ataflop.c
--- linux-test10-pre5/drivers/block/ataflop.c Wed Jul 5 20:24:40 2000
+++ linux/drivers/block/ataflop.c Tue Oct 24 15:33:40 2000
@@ -1571,8 +1571,6 @@
switch (cmd) {
case BLKROSET:
case BLKROGET:
- case BLKRASET:
- case BLKRAGET:
case BLKFLSBUF:
return blk_ioctl(device, cmd, param);
}
diff -ur linux-test10-pre5/drivers/block/blkpg.c linux/drivers/block/blkpg.c
--- linux-test10-pre5/drivers/block/blkpg.c Mon Mar 13 04:32:57 2000
+++ linux/drivers/block/blkpg.c Tue Oct 24 15:29:31 2000
@@ -29,7 +29,7 @@
*/
#include
-#include /* for BLKRASET, ... */
+#include
#include/* for capable() *
Re: PATCH: killing read_ahead[]
Rik van Riel wrote: > > On Tue, 24 Oct 2000, Martin Dalecki wrote: > > > The most amanzing thing is that the whole test10-pre5 kernel > > with this patch applied doesn't show any performance penalties > > for me at all! And of corse it's about 10k smaller... > > Ideally we should (IMHO) get rid of all MAX_BLKDEV arrays. > > They take up too much memory on small systems and aren't > big enough for big systems... Yes sure. The whole patch was just showing how those arrays actually HURT (the whole familiy of them) 1. Nobody really understands where which read_ahead does matter. 2. There is no discrimination between different device types on the same major number 3. MD and SCSI "work around" this by setting ridiculously high read ahead values... so you don't see the impact of this DAMN interface in benchmarks. 4. It's not just a problem of block devices it's a problem of char dev's as well. 5. Removing them is a prerequisite for getting rid of the STIUPID MAJOR(dev)/MINOR(dev) and famility of macros and of course wide major infor number spaes as well... 6. It's showing that it was a BAD IDEA to intermix block/char majors. 7. It's really really confusing many many device driver developers. Nobody seems to understand the intended semantics any longer. In esp. in parts of the kernel which got introduced past the 2.0 times. and so on... and of cores all the arrays involved in this game are: Controller->GenericDiskInfo.sizes = Controller->PartitionSizes; blksize_size[MajorNumber] = Controller->BlockSizes; ^^ max_sectors[MajorNumber] = Controller->MaxSectorsPerRequest; ^^ - /* -Initialize Read Ahead to 128 sectors. - */ - read_ahead[MajorNumber] = 128; + and others Not really a sight of "good interface design taste" at all. In esp. since I'm already pointing at this since SEVERAL YEARS. No wonder 2.4 takes ages to finish! <- If you never bite the bullet of mistakes from the early days (becouse they just require to go through nearly every driver). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: killing read_ahead[]
Jeff Garzik wrote: > > > Please have a look at the following patch and feel free to be scared > > by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the > > read_ahead[] array and during the whole past decade was! > > If you really care about clean internal interfaces this should be > > one of those prio number ONE targets to shoot at... > > > > The most amanzing thing is that the whole test10-pre5 kernel with this > > patch applied doesn't show any performance penalties for me at all! > > And of corse it's about 10k smaller... > > I agree with you and Rik that this array needs to go away... but > ripping out the feature is not the answer, IMHO. > > Can you work up a patch that instead changes the readahead to be a hash > table? The key could be a hash of the blkdev/chrdev pointer value (or > kdev_t for now). Considering the number of users, the hash table can be > pretty darn small for most machines, but we can easily scale its size > dynamically at boot if need be. > > That would give us the per-device granularity we need to actually make > the feature useful, and allow us to kill the hacks you mention in > existing drivers (like the MD and SCSI examples you cited). A log log time ago (about 2.3.xx) I actually posted a patch which was the preparation for *EXACTLY* this step and which contained a bit of *OBVIOUS* other cleanup. However those times I requested to get a confirmation that if I start to work *SERIOUSLY* on it then it wouldn't be for nothing. I don't intend to spend my spare time on such a thing without knowing IN FRONT that this work won't get ignored due to the IGNORANCE of some person. I didn't get any clean response... Anyway if you ask whatever I'm able to prepare such a patch the answer is - obviously yes. PS. This is an general problem of the "Open Source" developement modell - exagerous waiste of resources where many profesionalls don't wan't to be involved with - however if you would dare to invite me to France for a hack session of about 2-3 days I would deligtefully take hollidays from my current job or a prolonged weekend and do it anyway whatever "big L" says (or doesnt say ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)
Peter Samuelson wrote: > > > So which is the recommended compiler for each kernel version 2.2.x, > > 2.4.x(pre?) nowadays? > > * 2.91.66 aka egcs 1.1.2. It has been officially blessed for 2.4 and > has been given an informal thumbs-up by Alan for 2.2. (It does NOT > work for 2.0, if you still care about that.) > > * 2.7.2.3 works for 2.2 (and 2.0) but NOT for 2.4. > > * 2.95.2 seems to work with both 2.2 and 2.4 (no known bugs, AFAIK) and > many of us use it, but it is a little riskier than egcs. > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel. Works fine for me and 2.4.0-test10-pre5... however there are tons of preprocessor warnings in some drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test10-pre6: Use of abs()
Horst von Brand wrote:
>
> Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> both sides).
>
> abs() is used at least in:
>
> arch/i386/kernel/time.c
> drivers/md/raid1.c
> drivers/sound/sb_ess.c
>
> gcc warns about use of a non-declared function each time.
>
> No definition for the function is to be found (grep over all include/ comes
> up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
> Presumably gcc is using a builtin (it doesn't show up in System.map). Is
> this the desired state of affairs? Should a include/linux/stdlib.h be
Yes abs will be transformed into an internal function, which will be
fully
unrolled due to -O2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test10-pre6: Use of abs()
Jakub Jelinek wrote:
>
> On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> > Horst von Brand wrote:
> > >
> > > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > > both sides).
> > >
> > > abs() is used at least in:
> > >
> > > arch/i386/kernel/time.c
> > > drivers/md/raid1.c
> > > drivers/sound/sb_ess.c
> > >
> > > gcc warns about use of a non-declared function each time.
> > >
> > > No definition for the function is to be found (grep over all include/ comes
> > > up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
> > > Presumably gcc is using a builtin (it doesn't show up in System.map). Is
> > > this the desired state of affairs? Should a include/linux/stdlib.h be
> >
> > Yes abs will be transformed into an internal function, which will be
> > fully
> > unrolled due to -O2.
>
> No matter what it should be prototyped in some header. And all uses should
> be checked, because abs is
> int abs (int) __attribute__ ((__const__));
> and sometimes people use it on `long' instead (such a bug has been fixed in
> the kernel some months ago).
Of corse right! BTW. There are tons of places where log2 is calculated
explicitly in kernel which should be replaced with the corresponding
built
in functions as well (/dev/random code does it). And then If I remember
correctly
there is an attribute which is telling about internal functions
in declarations explicitly as well?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: killing read_ahead[]
Linus Torvalds wrote: > > On Wed, 25 Oct 2000, Rik van Riel wrote: > > > > OTOH, block-dev readahead makes sense for filesystems where > > the packing locality is close to the access pattern BUT NOT > > close to anything the page cache would recognise as being > > close. > > I dunno. The main reason I'd like to get the block devices into the page > cache is that right now there is no way to mmap them - something that can > potentially be _very_ useful, regardless of readahead. > > And quite frankly, the generic file readahead has been pounded upon and > tested a lot more than the block device read-ahead ever was. I bet it > performs better if for no other reason. And then of course the FS is the LOGICAL level of access to the device - so if read ahead matters then it's this level where it should happen - since this is the place where actual predictability of the next access (actually the assumption that the access will happen at least semi-sequentially) has good chances to be right. So you are completely right that the page-cache is the right place where the rahead logic should take place. I have just filled the argumentation gap ;-). -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)
Horst von Brand wrote: > > Martin Dalecki <[EMAIL PROTECTED]> said: > > Peter Samuelson wrote: > > [...] > > > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel. > > > Works fine for me and 2.4.0-test10-pre5... however there are tons of > > preprocessor warnings in some drivers. > > CVS (from 20001028 or so) gave a 2.4.0.10.6/i686 that crashed on boot, no > time to dig deeper yet. I was just using the compiler shipped by RedHat with all the fixes contained therein self compiled under glibc-2.1.95 on a system which some long time ago was RedHat-5.1 ;-). And it worked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test10-pre6: Use of abs()
Richard Henderson wrote: > > On Wed, Nov 01, 2000 at 09:46:19AM -0500, [EMAIL PROTECTED] wrote: > > What versions of gcc produce the built-in functions? > > 2.95 and previous. In 2.96 somewhere we fixed a bug that > automatically prototypes these builtin functions for you; > ie with current code you get an undeclared function warning. > > > And does it do so for *all* platforms? (i.e., PPC, Alpha, > > IA64, etc., etc., etc.) > > Yes. The thing about abs, though, is that it's "int abs(int)" > which does naughty things with longs on 64-bit targets. You're > much better off writing (x < 0 ? -x : x) directly. Thank's for answering it... I was already looking up the GCC source for an exact answer ;-). However what's the difference in respect of optimization between unrolling the abs function by hand and relying on the built in? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ESS device "1998"
Mo McKinlay wrote: > > I recently obtained an HP Omnibook XE2 laptop. It's a reasonably > nicely-specced machine, although (unsuprsingly) the hardware isn't too > well supported with Linux. > > I've given up on the internal modem (I'm 90% sure it's some kind of > software modem, and I have an external anyway), but I'm trying to get > some sort of audio to work via the internal sound device. > > Here's the output of 'lspci': The chip you are talking about is a maestro-3. It's a hybris chip between a CS and an Alegro. The OSS sound drivers support it already. However there is no free driver for it currently out there. If you get the current maestro open driver to recognize the chip at least the mixer will start to work. > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge > (rev 03) > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge > (rev 03) > 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) > 00:0a.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) > 00:0a.1 CardBus bridge: Texas Instruments PCI1225 (rev 01) > 00:0d.0 Multimedia audio controller: ESS Technology: Unknown device 1998 > 00:0d.1 Communication controller: ESS Technology: Unknown device 1999 > 01:00.0 VGA compatible controller: Silicon Motion, Inc.: Unknown device > 0710 (rev a3) > 20:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) > 20:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) > > I'm currently using 2.2.14 (plus whichever patches RH added for their 6.2 > release), and it doesn't seem to be supported. So.. simple question, does > anybody know if this 'card' is supported in a more recent kernel, or > whether there's something in 2.2.14 that works? > > [As an aside, from watching Windows boot, it seems to have some sort of > SoundBlaster compatibility, although it seems to lack MPU401 support or > emulation - and any attempts to use the Linux soundblaster stuff seems to > fail miserably :/] > > Any hints/clues/etc welcome. > > Many thanks, > > Mo. > > -- > Mo McKinlay > [EMAIL PROTECTED] > - > GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
Tim Riker wrote: > > ok, a very valid point. The "C++ kernel code" reference is very telling. > (ouch). ;-) > > Obviously the changes to support non-gcc compilers should have the goal > of minimal impact on gcc users lives. I recognize that the mainstream > will still use gcc. > > Q: Why should we help you make it possible to use a proprietary C > compiler? > > This is right on the money. I hope to show that is is all part of "World > Domination". ;-) I can easily see other paths to get there though, so > why this one? > > As is being discussed here, C99 has some replacements to the gcc syntax > the kernel uses. I believe the C99 syntax will win in the near future, > and thus the gcc syntax will have to be removed at some point. In the > interim the kernel will either move towards supporting both, or a > quantum jump to support the new gcc3+ compiler only. I am hoping a No I think that there will be just a switch for gcc along the lines of gcc --forget-our-extensions-use-c99-for-this-file. Gnu code is common enough to justify this. And nothing will change in old code ;-). It's only recently that the G++ people got around to throw away some extensions (on the C++ part). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > * Driver initializes mixer to 100% muted * Userspace app sets desired > > values to /dev/mixer * Userspace app opens /dev/dsp to play sound > > > I don't see where any sound can "escape" in this scenario, and it > > doesn't require any module data persistence... > > * User boots kernel > * User loads mixer app > * Sound module is autoloaded, defaults to zero levels. This is fine. > * User sets 'line in' level to appropriate level to listen to radio > * User closes mixer app > * Time passes > * Sound module is unloaded > * User continues to happily listen to radio through sound card > * Time passes > * User is listening intently to something on the radio > * Something wants to beep through /dev/audio > * Sound module is autoloaded again, default to zero levels. > This time it is _NOT_ fine. User is rightly pissed off :) > > It's fine to default to zero levels the first time the sound module is > loaded after booting. Not on subsequent reloads though. > > A long time ago, I made the sb16 driver use the persistent storage facility > of kerneld to store mixer levels. I was happy with this right up until > kerneld disappeared :) It was removed for good reasons. > I then made a version which read the current mixer levels back from the > hardware on initialisation, and didn't reset them. That didn't work on all > sb16 hardware, but it worked for me (tm). > > Persistent storage is the best way to do it though. It doesn't have to be > persistent over reboots, just during the lifetime of the kernel. No! The best way to do it are just *persistently loaded* modules. It's THAT simple! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > > > >Just load the driver at bootup and forget about it. Problem solved. > > > > I daily curse the name of whoever added autoload and autounload. > > Autoload maybe useful, autounload is just asking for problems. > > Deal with it. Hardware is also now auto load and auto unloading too. For 2.5 > hopefully a lot of this can be tidied up and done better - persistent storage > in the modules that is written to disk and put back by insmod/rmmod (in > userspace) will help a lot. Not quite: plugging physically hardware in and out is compleatly different then just loading a driver and unconditionally unloading it even when the hardware is still there! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Martin Mares wrote: > > Hi Alan! > > > If the sound card is only used some of the time or setup and then used > > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it > > especially on a low end box > > So why don't we allocate / free the DMA buffer on device open / close instead > of module insert / remove? If the reason lies in problems with allocation > of large chunks of contiguous memory, we're going to have exactly the same > problems when autoloading the module. > > I think that automatic loading / unloading of modules has been a terrible hack > since its first days (although back in these times a useful one) and that the > era of its usefulness is over. There are zillions of problems with this > mechanism, the most important ones being: Amen. >o It would have to preserve _complete_ device state over module reload. > For the sound card mixer settings discussed it's close to trivial, but > for example consider a tape drive and the problem of preserving tape > position after reload (probably including device reset causing tape rewind). > And what about textures loaded to memory of a 3D video card? > >o For many drivers, the "device currently open" concept makes no sense. > Consider a mouse driver whose only activity is to feed mouse events > to an event device. The mouse driver can be unloaded in any time (either > manually or perhaps automatically after the mouse gets unplugged), hence > it should have a use count == zero, but even if it seems to be unused, > it must not be unloaded just because of some timeout since the mouse > will cease to work. > >o It interferes with hotplug in nasty ways. Let's have a USB host controller > driver with currently no devices on its bus. It's also an example of a zero > use count driver, but it also must not be unloaded as it's needed for > recognizing newly plugged in devices. Plese add power-saving devices like in notebooks to the list as well. For example in my notebook the PC speaker loops through the maestro-3e. The BIOS is initializing the maestro with some sane mixer values but after a suspend cycle the pc speaker is compleatly off due to suspension of the maestro-3e chip and the leak of a *permanent* driver sitting around to handle the wakeup event. > I don't argue whether we need or need not some kind of persistent storage for > the modules (it might be a good idea when it comes to hotplug, but it should > be probably taken care of by the userspace hotplug helpers), but I think that > it has no chance to solve the problems with automatic unloading. > > We could of course attempt to circumvent the problems listed above by adding > some hints to module state which will say whether it's possible to auto-unload > the module or not even if it has zero use count, but it means another thing > to handle in all the drivers (well, at least another thing to think of whether > it's needed or not for each driver) and I think that the total effect of > the autounloading mechanism (a minimum amount of memory saved) in no way > outweighs the cost of implementing it right. And the pain for the user of the whole: Take the example of ALSA over-modularisation... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Alexander Viro wrote: > > On 9 Nov 2000, Mike Coleman wrote: > > > Alexander Viro <[EMAIL PROTECTED]> writes: > > > RMS had repeatedly demonstrated what he's worth as a designer > > > and programmer. Way below zero. You may like or dislike his ideology, > > > but when it comes to technical stuff... Not funny. > > > > Huh? > > > > > > > > *Hello*? GNU gcc? GNU emacs? Way below zero? *Hello*?!? > > > > > > Yes. GNU emacs. Bloated and ugly like hell. gcc. Codebase is anything but > pretty. Your point being? And no, it's not trolling. RMS really got no > taste - read his postings on _technical_ GNU lists and see yourself. Actually emacs is complete crap int terms of both ergonomy and coding. But the current gcc code base doesn't contain much from RMS anylonger. The "beauty" of lisp coded in C it is... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
Dietmar Kling wrote: > > Ok guys i take your arguments... > (i really loved to hear them) > > and i'd like to continue them in a > private discussion( but i am > tired now ... :) ) > > but a last one i cannot resist... > > > but why are your ideas not widespread and > so successful like kde,gnome,windows? Please don't put KDE into the same bunch as gnome or windows. KDE is in fact *well designed*! In esp. 2.0 > maybe because they suck at some point? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"Justin T. Gibbs" wrote: > > >> BSD has curproc, but that is considerably less likely to be > >> used in "inoccent code" than "current". I mean, "current what?". > >> It could be anything, current privledges, current process, current > >> thread, the current time... > > > >I see and I assume calling a random collection of data > > > > u.something > > > >in BSD was even more logical 8) > > The only place I've seen this in BSD is for defining a "union" of > data within a structure. I don't think its ever been #defined into > a namespace. > > >current is a completely rational name. The problem with current on some of > >our ports right now is that its a #define. That is a trap for the unwary and > >one day wants fixing. > > Exactly. > > >curproc would be incorrect for linux since its the current task, > >and a task and unix process are not the same thing > > I'm aware of the difference. I only mentioned "curproc" as an example of > similar brokeness that has less of a chance of catching the uninitiated. > What about "curtask" or "curthread"? What's wrong with current? It's perfectly fine, since it's the main data context entity you are working with during it's usage... Just remember it as CURRENT MAIN PROBLEM the kernel is struggling with at time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"Justin T. Gibbs" wrote: > > > > >What's wrong with current? It's perfectly fine, since it's the main data > >context entity you are working with during it's usage... Just remember > >it as > >CURRENT MAIN PROBLEM the kernel is struggling with at time. > > What's wrong with the aic7xxx driver storing the "user", "goal", and > "current" transfer negotiation settings for a device in a structure > with fields by those names? Nothing save the fact that "current" is > a #define in linux. > > Anyway, I've said my peace. The driver will properly work around > the namespace problem. Just save space and call it curr instead ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ident of whole-disk ext2 fs
Dnia Wto 19. Grudzie? 2000 18:45, Andries Brouwer napisa?: > On Tue, Dec 19, 2000 at 06:14:04AM -0500, Paul Gortmaker wrote: > > I always disliked the unknown partition table messages you get when you > > mke2fs a whole disk and don't bother with a table at all, so I fixed it. > > Output before/after shown below: > > > > Partition check: > > hda: hda1 hda2 > > - hdd: unknown partition table > > + hdd: whole disk EXT2-fs, revision 1.0, 1k blocks, status: clean. > > A nice boot message. > > But what if you just replace the "unknown partition table" What about the more correct. hdd: no partition table There is no presumed "unknown" partition table at all when we can't recognize it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
Ragnar Hojland Espinosa wrote: > > On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote: > > Some arguments why not to use it in the kernel : > > > > - C++ gives overhead. With something like a kernel that's unwanted. > > You pay for what you use, no less no more. C++ compilers don't generate > bloated code `per se' but, yes, it's easier to make mistakes that degenerate > into bloatedness. > > > - Things like exception handling is hard to do in a kernel. > > You don't need it. And if you don't use it you don't pay for it. > > > - The're a lot more people that know C than C++ > > Let's put it the other way... there aren't many people who know > C++ around. Well, there are less people who understand the kernel. Then, > maybe, to make it more accessible, we should dumb it down. > > > And I probably forgot a few :) > > Sure :) > > Someone mentioned they preferred C because they knew exactly what the > compiler would be generating. I wonder if they got this knowledge in some > magic way, and what makes them think that they couldn't learn what C++ > compilers do (at least G++) Simple: The fact that G++ is constantly changing what it's generatign even between minor numbers: 1. Calling conventions. 2. Name mungling. 3. Construct semantics. 4. Run time support (stdio and STL). 5. New features here and there... and so on and so on... You just can't follow them all in case you are not interrested in becoming a compiler developer yourself! And then there are tons of hidden code generation there: 1. Constructors/Destructors 2. Templates 3. Operator overloding - which can be very successfully used to hide the true semantic of the operators from the code reader. In esp. copy contructors and such... 4. Hidden inheritance due to header mess... 5. Sic and fragile semantics of all language components! > Of course, yes, I do agree that if the kernel is in C and putting in C++ > requires more than some little localized glue or similar, C++ shouldn't go > in. > > But I'll never understand this C++ aversion. C++ is fine for GUI coding and such but it's no good in case you really need full controll of the underlying machine - and the only way to get this is to have full controll of what's generated by the compiler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Marc Lehmann wrote: > > On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > > > If you don't like this, I suggest you send mail complaining to RedHat. > > > Customer complaints are going to be the only way that RH is going to be > > > influenced not to play games like this > > > > Remind me next time I get to deal with crap from VA customers because VA > > Talk about the pot calling the kettle black. I think you owe an apology > > Actually, it's redhat who owes an apology to the commnity at large for > _already_ creating a maintainance hassle for gcc and other free software > projects because they receive bogus bug reports because redhat shipped > a broken, experimental, unreleased compiler as if it were an official Get real: RedHat owns cygnus and cygnus owns GCC so what do you complain about? It's up to them to decide which compiler is stable or which isn't. (Froget about the "committe" stuff...) And then there is [EMAIL PROTECTED] - so wht's up with the glibc? I can understand redhat somehow. There are good reasons for them to take even CVS snaps and ship them instead of *very* outdated so called stable versions. > version. Worse, creating a maintainance nightmare for almost everybody by > making redhat binary incompatibly to other linux distributions, therefore > effectively forking gnu/linux in a way unseen before.(*) > > However, I can understand that you have to support redhat and have > probably lost your neutrality. > > (*) redhat is a major distribution and obviously now plays monopoly games. > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > | > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Alan Cox wrote: > > > > They released a supported ex-Cygnus people approved compiler. > > > > Which still makes it an broken, experimental, unreleased and unofficial > > compiler, with all the consequences I said. > > And didnt you write something called pgcc once. And then there isn't anything I could see which would prohibit anybody from taking gcc-2.96 and ship it in any distro they wish too. Alan you are in full right here the gcc-2.96 DOES a significantly *better* job on in esp. C++ for example then any other gcc before - at least on the arch's which really matter those days. The PGCC never really worked. In fact on TeX at least it generated worder code then the plain gcc-2.7.3 those day's - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Marc Lehmann wrote: > If you disagree personally or technically with me you either say this > in public or private or keep quiet. Attacking me over totally unrelated > things is obviously some maneuver to distract people from the real, > kernel-related question, and I have no idea why you are doing this... > > After all, even if you do work for redhat, the way redhat actively damages > linux (the kernel), other distributions (who probably would like to do the > same) and free softwrae projects JUST NOW should not leave you quietly > obeying (mind you, I am not the only one saying this). WHAT? Are you nuts - they pay breed for many of the core kernel developers - I think if they didn't those would actually have entierly stopped working on Linux otherwise just after finishing scool and going into the real world out there. You can't hardly call this behaviour *demanging*!!! And then there is Alan himself! > Redhat certainly is not special compared to other distros. But redhat is > the largest one, and they started the trend to monopolize the market at > the cost of morality, ethics and free software. Just tell me what's about ethics involved here - they just do business here and they do it in a *very* open way indeed. This is what the GPL is explicitly permitting them to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Richard Henderson wrote: > Frankly, I didn't even consider C++ ABI compatibility with other > Linux vendors, since I think that's a losing proposition until > everyone is using gcc3. We were _already_ incompatible, since > there are a mix of egcs and gcc versions involved. C++ ABI breaking: SuSE managed to break the VShop application in an entierly insane way between releases 6.1 and 6.2 - they stiupid did recompile the libstdc++ with a new compiler and didn't even bother to increment the binary version of this library At RedHat at least they know what they are changing... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Igmar Palsenberg wrote: > > > I wouldn't mind, either, if this didn't mean that programs compiled > > on rehdat need redhat versions of the development toolchain / runtime > > environment to use them :( Ever tried to recompile SuSE apache from the src.rpm they provide? I wish you good louck getting your hands on adabas and other stuff they require, which doesn't come with the distribution itself THAT is OFFENDING! Not just the fact whatever who want's to be the offical version of something - read: "With blessing from RMS instead of the employer of the people who do the actual work". > And you say that programs developed on for example SuSE don't need a SuSE > enviroment ?? > > Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel debugging
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed, fixed) returntype functionname
> (PARM(parameters)){
> DEBUG(ENTRY,SUBSYSTEM, module, functionname);
> /* function body starts */
> do something
> do something
> on success goto ok;
> on failure goto failure_reason_name;
> /* function body ends */
> ok:
> on ok do something
> DEBUG(EXIT,SUBSYSTEM, module functionname, OK);
> exit or return whatever
> failure_reason_name;
> on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name);
> exit or return whatever
> failure_reason_name1;
> on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1);
> exit or return whatever
> };
> --
Please have a tought look at the floppy tape streamer driver to see why
this
is a BAD IDEA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Ingo Molnar wrote: > > On Tue, 5 Sep 2000, Andi Kleen wrote: > > > My point was basically that omitting useful debugging tools makes it > > not any less likely that people use the (A) strategy (easy fix instead > > of real understanding). For some people it is so painfull to work with > > raw dumps that they want to get out of that pain as quickly as > > possible, like with just adding an if (!ptr) return; and be done with > > it. > > well, they will sooner or later notice that it's easier to fix bugs by > following the development of the kernel and understanding the underlying > principles and the code. As elitist as it might seem, we rather need 10 > highly skilled developers who understand the kernel than 100 moderately > skilled ones who know how to operate a kernel debugger and barely anything > else. [this is not an insult towards people with less experience - having > less experience is just a temporary stage of a process, nothing else. But > if it becomes the end station thats a problem IMHO.] > > Ingo There is a nice discussion about the online-debugging vers. the "doing it the hard way" approach in some software engineering books out there. (Sorry I don't have them here at hand, so I can't give an exact refference - it was either the famous "Mythical Man Month" or "Warum is Software so Teuer und andere Mythen der Informationstechnologie" by some other guy whose name I don't remember ;-). However I'm quite sure someone here will remember it well... Basically in the book I have in mind the author was describing the result's of a spinoff company from IBM which was trying to make some money on the added facility of "heart surgery" to some early IBM OS. (IBM did release them just for the price of a symbolic 1$)/ Basically after some time they have realized that yes casual debugging was easier and more productive, but after long the statistical view showed that the code quality was rather degrading by using on the fly debuggers instead of improving. --- Sometimes the obvious isn't the RIGHT THING becouse most of the time the easy fixes are just band aids hiding the trough problems. Therefore I would rather like to back-up the position of Ingo. And finally I would like to emphasize that every singe additional facility doesn't come free - It's adding complexity which is a source of possible problems in itself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
"Jeff V. Merkey" wrote: > > Ingo Molnar wrote: > > > > On Tue, 5 Sep 2000, Jeff V. Merkey wrote: > > > > > Your arguments are personal, not technical. [...] > > > > no, my arguments are technical, but are simply focused towards the > > conceptual (horizontal) development of Linux, not the vertical > > development of Linux (drivers) and support issues. > > They seem focused on keeping us in the dark ages. We need tools to make > it faster and easier for folks to perform kernel development and make > field support of Linux easier. No I don't agree. There are other areas where fast progress is by far more desirable then inside the kernel - PLEASE KEEP THE KERNEL dev. slow - which in the practice automatically translates into STABILITY of interfaces ;-). What's only needed fast are just device drivers. I don't care whatever it takes 2 or 3 years between major kernel releases - even this is twice the freq of NT updates already! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Andrea Arcangeli wrote:
>
> On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > Better would be to use statement blocks like
> > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with functions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Penguin logos
"Albert D. Cahalan" wrote: > > Geert Uytterhoeven writes: > > > - The colors for the 16 color logo are wrong. We used a hack to > > give the logo its own color palette, but this no longer works > > as a side effect of a console color map bug being fixed a while > > ago. The solution is to replace the logo with a new one that > > uses the standard VGA console palette. > > Good idea, but the feet don't look too good. Either dither a bit, > or pick a single color for the feet. Maybe a checkerboard-dither > would get close to the right color without looking grainy. > > > - There are still some politically-incorrect (PI) logos of a penguin > > holding a glass of beer or wine (or perhaps even worse? :-). > > Those also just look bad. The drink sort of floats above the penguin's > foot. It really looks like it was just pasted onto the image. > > The arch-specific logos look bad in general, and the swirly gray > background isn't so great either. Why not use the original image? I agree fully about the swirly gray - it's just looks ugly chlidish, dilletantic and very tasteless... plain color or some gui alike border would look much better. > > > Changes: > > 1. Update the frame buffer console code to no longer change the > > palette when displaying the 16 color logo. Remove the tricks > > to load the logo palette in unused palette entries on displays > > with >= 32 colors. > > I used to have only 256 colors on my display. I upgraded because > there still isn't a global system palette. I'd have been happy > enough with 256 colors allocated in a sane way, for kernel & X: > > 1. the 16 VGA colors and extra 4 Windows colors (so Wine can work) > 2. the 216 Netscape colors > 3. gray: 0x00, 0x11, 0x22... 0xff, plus both 0x7f and 0x80 > 4. everything else reserved for future global allocation > > The current situation is way too painful to use. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux localization
Alan Cox wrote: > > > My work will concern with the internationalization of Linux > > So, could anybody tell me what kinds of features should be in the > > consideration when linux be localized from english to Japanese or chinese, > > say using 2 bytes character set. > > Most of the Linux userspace libraries are set up for handling UTF8 and > other internationalisations. Fonts are more of an issue and lack of application > translations. Filenames are defined to be UTF8. Something along the lines of pcvt (*BSD) for full userspace line discipline handling on the console would be great. Read: much saner then trying to do this all in kernel like linux does currently. Maybe the linux way was justified during the days of 386sx 16MHz somehow. Currently it's relly just plain ugly. Try using some other character set then iso8859-1 on the linux console to see why. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
Rik van Riel wrote: > > On Tue, 13 Mar 2001, Albert D. Cahalan wrote: > > > Bloat removal: being able to run without /proc mounted. > > > > We don't have "kernel speed". We have kernel-mode screwing around > > with text formatting. > > Sounds like you might want to maintain an external patch > for the embedded folks... Not the embedded folks!!! The server folks laugh histerically all times they go via ssh to a trashing busy box to see what's wrong and then they see top or ps auxe under linux never finishing they job: > > regards, > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 5Mb missing...
Jonathan Morton wrote: > > >> If crashes are routine on this machine, I'd recommend that you take > >> a serious look at your ram. (or if you're overclocking, don't) > > > >Crashes were routine, and I was not overclocking, so I took Mike's > >advice and bought a new 256MB DIMM. The computer hasn't crashed > >once since I installed it. Now, though, I have a curious though > >fairly irrelevant problem. My kernel apparently sees less RAM than > >I have. > > The kernel itself takes up some RAM, which is simply subtracted from the > "total memory available" field in the memory summaries available to > user-mode processes. This is perfectly normal. The kernel reserves 4m for hilself. The off by one error is a rounding bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Rik van Riel wrote: > > On Sat, 23 Mar 2002, Martin Dalecki wrote: > > > Uptime of a process is a much better mesaure for a killing > > candidate then it's size. > > You'll have fun with your root shell, then ;) You mean the remote one? > The current OOM code takes things like uptime, used cpu, size > and a bunch of other things into account. > > If it turns out that the code is not attaching a proper weight > to some of these factors, you should be sending patches, not > flames. Did I say anything insulting? I have just stated what I think is more important... BTW> it's not quite obvious that You have to look into oom_kill to find it in the kernel source where to look at. (Yes I did just find /usr/src/linux -name "oom*" becouse I happen to remember but! OK i will just place - in front of the description lines where I think that you where mislead: * Good in this context means that: * 1) we lose the minimum amount of work done -* 2) we recover a large amount of memory * 3) we don't kill anything innocent of eating tons of memory -* 4) we want to kill the minimum amount of processes (one) * 5) we try to kill the process the user expects us to kill, this *algorithm has been meticulously tuned to meet the priniciple *of least surprise ... (be careful when you change it) The following is a wrong assumtion. You usually nice processes to the background just to guarantee for example smoot interaction just in case you won't login in in some time to the machine. For example let's have an dedicated http server, which does a lot of embedded perl. It's quite clever to renice it back, just in case this remote machine get's overloaded, becouse otherwise your chances to get a login in case the machine starts to trash, would be much worser. But this doesn't mean that the process isn't more important - becouse you do it to make the machine crowl through high load peaks and still let you in in case you have something urgent to do on it. /* * Niced processes are most likely less important, so double * their badness points. */ if (p->nice > 0) points *= 2; BTW> Why the hell you don't just use a polynomial approximation for int_sqrt - the range of values is very closed an you are working in a finite ring anyway - you could very easly find a simple approximation which wouldn't need any looping. This should be reversted: points /= int_sqrt(cpu_time); points /= int_sqrt(int_sqrt(run_time)); points = p->mm->total_vm; /* * CPU time is in seconds and run time is in minutes. There is no * particular reason for this other than that it turned out to work * very well in practice. This is not safe against jiffie wraps * but we don't care _that_ much... */ cpu_time = (p->times.tms_utime + p->times.tms_stime) >> (SHIFT_HZ + 3); run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10); points /= int_sqrt(cpu_time); points /= int_sqrt(int_sqrt(run_time)); == NOW I SEE THE MOST IMPORTANT MISTAKE: There should be a de-normalization of the units CPU_time/total_uptime RUN_time/total_uptime mem/total_mem. Otherwise you can't map the intended logics sufficiently safe on to the calculation you do. You compare bits with seconds - which is WRONG. Let: m := memmory used by the process M := the total memmory in the system. c := cpu time used by the process u := uptime of the process. U := uptime of the system Then you calculate points as (m / sqrt(c)) / sqrt(sqrt(r)) Which is just very wired function with a non homogen behaviour. (Just take the first derivative of it in any dimension to see what I mean) You should calculate to represent you intended logics: x * (m / M) + y * (U / c) + z * (U / u), where x y z are constants representing the wighting heuristic importance one gives to those particular measure points. A simple *normalized* polynom the only thing people and computers can realy deal with. > (the code is full of comments, so it should be easy enough to > find your way around the code and tweak it until it does the > right thing in a number of test cases) > > regards, > > Rik > -- > Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml > > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Stephen Clouse wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> > AMEN! TO THIS!
> > Uptime of a process is a much better mesaure for a killing candidate
> > then it's size.
>
> Thing is, if you take a good study of mm/oom_kill.c, it *does* take start time
I did thing is Rik did use a non normalized formula in oom_kill for the
calculation of the kill penalty a process get's. This is the main
reason for the non controllable behaviour of it.
> into account, as well as CPU time. The problem is that a process (like Oracle,
> in our case) using ludicrous amounts of memory can still rank at the top of the
> list, even with the time-based reduction factors, because total VM is the
> starting number in the equation for determining what to kill. Oracle or what
> not sitting at 80 MB for a day or two will still find a way to outrank the
> newly-started 1 MB shell process whose malloc triggered oom_kill in the first
> place.
This is due to the broken calculation formula in oom_kill().
>
> If anything, time really needs to be a hard criterion for sorting the final list
> on and not merely a variable in the equation and thus tied to vmsize.
>
> This is why the production database boxen aren't running 2.4 yet. I can control
> Oracle's usage very finely (since it uses a fixed memory pool preallocated at
> startup), but if something else decides to fire up on there (like the nightly
> backup and maintenance routine) and decides it needs just a pinch more memory
> than what's available -- ick. 2.2.x doesn't appear to enforce new memory
> allocation with a sniper rifle -- the new process just suffers a pleasant ("Out
> of memory!") or violent (SIGSEGV) death.
And you should never ever overcommit memmory to oracle! Don't make the
buffers bigger then half the memmory in the system really. There ARE
circumstances where oracle is using all available memmory in very random
manner.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Rik van Riel wrote: > > On Sat, 23 Mar 2002, Martin Dalecki wrote: > > > This is due to the broken calculation formula in oom_kill(). > > Feel free to write better-working code. I don't get paid for it and I'm not idling through my days... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
SodaPop wrote: > > Rik, is there any way we could get a /proc entry for this, so that one > could do something like: I will respond; NO there is no way for security reasons this is not a good idea. > cat /proc/oom-kill-scores | sort +3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
I have a constructive proposal: It would make much sense to make the oom killer leave not just root processes alone but processes belonging to a UID lower then a certain value as well (500). This would be: 1. Easly managable by the admin. Just let oracle/www and analogous users have a UID lower then let's say 500. 2. In full compliance with the port trick done by TCP/IP (ports < 1024 vers other) 3. It wouldn't need any addition of new interface (no jebanoje gawno in /proc in addition() 4. Really simple to implement/document understand. 5. Be the same way as Solaris does similiar things. ... Damn: I will let my chess club alone toady and will just code it down NOW. Spec: 1. Processes with a UID < 100 are immune to OOM killers. 2. Processes with a UID >= 100 && < 500 are hard for the OOM killer to take on. 3. Processes with a UID >= 500 are easy targets. Let me introduce a new terminology in full analogy to "fire walls" routers and therabouts: Processes of category 1. are called captains (oficerzy) Processes of category 2. are called corporals (porucznicy) Processes of category 2. are called privates (¿o³nierze) ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
[EMAIL PROTECTED] wrote: > > Please point me to an Operating System that runs on any commonly available > platform and fits your requirements. > Nick You don't beleve me if I tell you: DOS extender and JVM (Java Virtual Machine) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
SodaPop wrote: > > On Fri, 23 Mar 2001, Martin Dalecki wrote: > > > SodaPop wrote: > > > > > > Rik, is there any way we could get a /proc entry for this, so that one > > > could do something like: > > > > I will respond; NO there is no way for security reasons this is not a > > good idea. > > > > > cat /proc/oom-kill-scores | sort +3 > > Oh, you mean like /proc/kcore is a bad idea for security reasons? Yes. It should be the good old /dev/core anyway. But its far more obscure to hack at, since it isn't plain text, so basically it's far more difficult to get mands on it... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
[EMAIL PROTECTED] wrote: > > [to various people] > > No, ulimit does not work. (But it helps a little.) > No, /proc/sys/vm/overcommit_memory does not work. > > [to Alan] > > > Nobody feels its very important because nobody has implemented it. > > Yes, that is the right response. > What can one say? One can only do. Please just expect a patch for tomorrow ;-). The only thing I have currently to do is testing. I will be using the installation process of the ORACLE iAS 9i for linux on my notebook, becouse it used to trigger oom for me VERY frequently. So far all things BEHAVE... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] OOM handling
Martin Dalecki wrote:
>
> I have a constructive proposal:
>
> It would make much sense to make the oom killer
> leave not just root processes alone but processes belonging to a UID
> lower
> then a certain value as well (500). This would be:
>
> 1. Easly managable by the admin. Just let oracle/www and analogous users
>have a UID lower then let's say 500.
>
> 2. In full compliance with the port trick done by TCP/IP (ports < 1024
> vers other)
>
> 3. It wouldn't need any addition of new interface (no jebanoje gawno in
> /proc in addition()
>
> 4. Really simple to implement/document understand.
>
> 5. Be the same way as Solaris does similiar things.
>
> ...
>
> Damn: I will let my chess club alone toady and will just code it down
> NOW.
>
> Spec:
>
> 1. Processes with a UID < 100 are immune to OOM killers.
> 2. Processes with a UID >= 100 && < 500 are hard for the OOM killer to
> take on.
> 3. Processes with a UID >= 500 are easy targets.
>
> Let me introduce a new terminology in full analogy to "fire walls"
> routers and therabouts:
>
> Processes of category 1. are called captains (oficerzy)
> Processes of category 2. are called corporals (porucznicy)
> Processes of category 2. are called privates (¿o³nierze)
OK I just did it. as I already told I have "stress tested it" by
installing the Orcale insternet application server suide
on a hoplessly underequipped box ("only" 128MByte RMA).
The assorted patch is attached.
Since I'm one day late up to my promise to provide this
patch it's actually fascinating that already 4 people (in esp. not
newbees requesting a new /proc entry for everything)
for reassurance that I will indeed implement it... Well
this kind of "high" and "eager" feadback seems for me to indicate
that there is very serious desire for it. And then of course I
just have to ask our people working with DB's here at work as well :-).
Ah... and of course I think this patch can already go directly
into the official kernel. The quality of code should permit
it. I would esp. request Rik van Riel to have a closer look
at it...
diff -urN linux/mm/oom_kill.c linux-new/mm/oom_kill.c
--- linux/mm/oom_kill.c Tue Nov 14 19:56:46 2000
+++ linux-new/mm/oom_kill.c Sun Mar 25 17:17:34 2001
@@ -1,18 +1,64 @@
/*
* linux/mm/oom_kill.c
- *
+ *
* Copyright (C) 1998,2000 Rik van Riel
* Thanks go out to Claus Fischer for some serious inspiration and
* for goading me into coding this file...
*
- * The routines in this file are used to kill a process when
- * we're seriously out of memory. This gets called from kswapd()
- * in linux/mm/vmscan.c when we really run out of memory.
- *
- * Since we won't call these routines often (on a well-configured
- * machine) this file will double as a 'coding guide' and a signpost
- * for newbie kernel hackers. It features several pointers to major
- * kernel subsystems and hints as to where to find out what things do.
+ * Sat Mar 24 22:07:15 CET 2001 Marcin Dalecki <[EMAIL PROTECTED]>:
+ *
+ * Replaced the original algorith with something reasonably, predictable
+ * and managable. I will call this "Stalins Eviction".
+ */
+
+/*
+ * The routines in this file are used to kill a process when the system is
+ * entierly out of memmory (both: RAM and swap). This gets called from
+ * kswapd() in linux/mm/vmscan.c when we are in total starvation due to the
+ * fact, that the only thing the system is busy at, is to try to allocate some
+ * physical memmory page, where there are no pages anymore left. In such it
+ * does make perfect sense to kill some offending process, just to make the
+ * system go on and survive.
+ *
+ * IT IS A LAST RESORT!
+ *
+ * ALLERT: In contrast to popular beleve the invention of the mechanism
+ * presented here IS IMPORTANT for system security reasons. It is preventing
+ * one border corner of an easy DNS attack in case the sysadmin didn't take
+ * other measures, which he either overworked or incompetent as he is usually
+ * doesn't.
+ *
+ * Basically the eviction goes on as follows:
+ *
+ * 1. Normal interactive user processes are the first candidates for a shoot.
+ * We consider all users with a UID >= 500 as normal interactive users.
+ *
+ * 2. If there are no processes started by a normal interactive user, we aim
+ * at the processes from nonessential processes (for the "live" of the system
+ * as a whole). We consider users with a UID >= 100 and < 500 as essential
+ * service user.
+ *
+ * 3. If this still isn't the case we start to shut down the system components
+ * peace by peace... (UID < 100).
+ *
+ * In fact the heuristics used to determine, at which of the process classes
+ * to
Re: [PATCH] Prevent OOM from killing init
Doug Ledford wrote: > > Horst von Brand wrote: > > > > "Christian Bodmer" <[EMAIL PROTECTED]> said: > > > > > I can't say I understand the whole MM system, however the random killing > > > of processes seems like a rather unfortunate solution to the problem. If > > > someone has a spare minute, maybe they could explain to me why running > > > out of free memory in kswapd results in a deadlock situation. > > > > OOM is not "normal operations", it is a machine under very extreme stress, > > and should *never* happen. To complicate (or even worse, slow down or > > otherwise use up resources like memory) normal operations for "better > > handling of OOM" is total nonsense. > > Puh-Leeze. Let's inject some reality into this conversation: > > [dledford@aic-cvs dledford]$ more kill-list > Mar 10 22:02:34 monster kernel: Out of Memory: Killed process 475 (identd). > Mar 10 22:03:25 monster kernel: Out of Memory: Killed process 660 (xfs). ... > Mar 22 15:45:54 monster kernel: Out of Memory: Killed process 504 (atd). > Mar 22 16:12:13 monster kernel: Out of Memory: Killed process 524 (sshd). > [dledford@aic-cvs dledford]$ > > What was that you were saying about "should *never* happen"? Oh, and let's > not overlook the fact that it killed off mostly system daemons to start off > with while leaving the real culprits alone. Once it did get around to the > real culprits (diff and tar), it wasn't even killing them because they were > overly large, it was killing them because it wasn't reclaiming space from the > buffer cache and page cache. All of the programs running on this machine were > never more than roughly 256MB of program code, and this is a 1GB machine. This is due to the fact that Riks killer doesn't normalize the resource units it's using for measure. Basically the current penatly calculations are a good random number generator. > This behavior is totally unacceptable and, as Alan put it, is a bug in the > code. It should never trigger the oom killer with 750+MB of cache sitting > around, but it does. If you want people to buy into the value of the oom > killer, you've at least got to get it to quit killing shit when it absolutely > doesn't need to. > > To those people that would suggest I send in code I only have this to say. > Fine, I'll send in a patch to fix this bug. It will make the oom killer call > the cache reclaim functions and never kill anything. That would at least fix > the bug you see above. Please just apply it to the patch I have recently send... It will help more :-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Mike Galbraith wrote: > > On Sat, 24 Mar 2001, Doug Ledford wrote: > > [snip list of naughty behavior] > > > What was that you were saying about "should *never* happen"? Oh, and let's > Get off your lazy butts and do something about it. Don't work on the > oom-killer though.. that's only a symptom. Work on the problem instead. You are absolutely right about the fact that there are serious memmory balancing problems out there as well. But ther oom_killer.c needs to be changed as well - becouse in it's current state it's buggy as hell as well. You propably know that you earn stability in SW systems by making them survive the borderline conditions... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Jeff Garzik wrote: > > Also for 2.5, kdev_t needs to go away, along with all those arrays based > on major number, and be replaced with either "struct char_device" or > "struct block_device" depending on the device. > > I actually went through the kernel in 2.4.0-test days and did this. > Most kdev_t usages should really be changed to "struct block_device". > The only annoyance in the conversion was ROOT_DEV and similar things > that are tied into the boot process. I didn't want to change that and > potentially break the boot protocol... Please se the patches I have send roughly a year to the list as well. It's actually NOT easy. In esp the SCSI and IDE-CD usage of minor arrays is a huge obstacle. -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Benoit Garnier wrote: > > Szabolcs Szakacsits wrote : > > > But if you start > > to think you get the conclusion that process killing can't be avoided if > > you want the system keep running. > > What's the point in keeping the OS running if the applications are silently > killed? > > If your box is running for example a mail server, and it appears that > another process is juste eating the free memory, do you really want to kill > the mail server, just because it's the main process and consuming more > memory and CPU than others? Yes bloody dumn, becouse I can then go no to the box, blacklist the smapper causing this with ipchains (or whatever it's called) and restart sendmail - WITHOUT DRIVING 1900km. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small but linked problems:
>
> - malloc() never returned 0 when the system ran out of memory, instead the OOM
>killer was triggered. Now, malloc() will return 0 if the calling process is more
>than 4 times the size of the amount of free memory. As a speedup, available swap
>space is not considered unless physical memory is not sufficient to contain the
>process. Note that if overcommit_memory is switched on, malloc() will never return 0
>anyway.
>
> - OOM killer was triggered too early - now takes account of buffer and cache memory,
>which can be cannibalised before the system has completely run out.
>
> - OOM killer badness() factors readjusted in favour of Oracle-like processes
>(consuming 10's of MB of RAM but up for 3 days or so and with a low-order UID? Now
>less likely to be killed...)
>
> --- begin oom-patch.diff ---
> diff -u linux-2.4.1.orig/mm/mmap.c linux/mm/mmap.c
> --- linux-2.4.1.orig/mm/mmap.c Mon Jan 29 16:10:41 2001
> +++ linux/mm/mmap.c Sat Mar 24 19:29:51 2001
> @@ -54,6 +54,7 @@
> */
>
> long free;
> + struct sysinfo swp_info;
>
> /* Sometimes we want to use more memory than we have. */
> if (sysctl_overcommit_memory)
> @@ -62,8 +63,32 @@
> free = atomic_read(&buffermem_pages);
> free += atomic_read(&page_cache_size);
> free += nr_free_pages();
> - free += nr_swap_pages;
> - return free > pages;
> +
> + /* Attempt to curtail memory allocations before hard OOM occurs.
> +* Based on current process size, which is hopefully a good and fast
>heuristic.
> +* Also fix bug where the real OOM limit of (free == freepages.min) is not
>taken into account.
> +* In fact, we use freepages.high as the threshold to make sure there's
>still room for buffers+cache.
> +*
> +* -- Jonathan "Chromatix" Morton, 24th March 2001
> +*/
> +
> + if(current && current->mm)
> + free -= (current->mm->total_vm / 4);
> +
> + free -= freepages.high;
> +
> + /* Since getting swap info is expensive, see if our allocation can happen in
>physical RAM */
> + if(free > pages)
> + return 1;
> +
> + /* Use the number of FREE swap pages, not the total */
> + si_swapinfo(&swp_info);
> + free += swp_info.freeswap;
> +
> + if(free > pages)
> + return 1;
> +
> + return 0;
> }
>
> /* Remove one vm structure from the inode's i_mapping address space. */
> Only in linux/mm/: mmap.c~
> diff -u linux-2.4.1.orig/mm/oom_kill.c linux/mm/oom_kill.c
> --- linux-2.4.1.orig/mm/oom_kill.c Tue Nov 14 18:56:46 2000
> +++ linux/mm/oom_kill.c Sat Mar 24 20:35:20 2001
> @@ -76,7 +76,9 @@
> run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);
>
> points /= int_sqrt(cpu_time);
> - points /= int_sqrt(int_sqrt(run_time));
> +
> + /* Long-running processes are *very* important, so don't take the 4th root */
> + points /= run_time;
>
> /*
> * Niced processes are most likely less important, so double
> @@ -93,6 +95,10 @@
> p->uid == 0 || p->euid == 0)
> points /= 4;
>
> + /* Much the same goes for processes with low UIDs */
> + if(p->uid < 100 || p->euid < 100)
> + points /= 2;
> +
> /*
> * We don't want to kill a process with direct hardware access.
> * Not only could that mess up the hardware, but usually users
> @@ -192,12 +198,20 @@
> int out_of_memory(void)
> {
> struct sysinfo swp_info;
> + long free;
>
> /* Enough free memory? Not OOM. */
> - if (nr_free_pages() > freepages.min)
> + free = nr_free_pages();
> + if (free > freepages.min)
> + return 0;
> +
> + if (free + nr_inactive_clean_pages() > freepages.low)
> return 0;
>
> - if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
> + /* Buffers and caches can be freed up (Jonathan "Chromatix" Morton) */
> + free += atomic_read(&buffermem_pages);
> + free += atomic_read(&page_cache_size);
> + if (free > freepages.low)
> return 0;
Ahh this will make the oom killer robust against misbalanced
MM. I will assimiliate this idea.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Stephen Satchell wrote: > > At 12:41 AM 3/25/01 +0100, you wrote: > >If your box is running for example a mail server, and it appears that > >another process is juste eating the free memory, do you really want to kill > >the mail server, just because it's the main process and consuming more > >memory and CPU than others? > > > >Well, fine, your OS is up, but your application is not here anymore. > > If you have a mission-critical application running on your box, add it to > the inittab file with the RESPAWN attribute. That way, OOM killer kills > it, init notices it, and init restarts your server. That makes me actually rolling on by back... Just try to add oracle to inittab crash it and watch it grabefully restarting by repawn! > By the way, are the people working on the OOM-killer also working to avoid > killing task 1? Already done. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Linus Torvalds wrote: > > On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote: > > > > We need a size, and I am strongly in favor of sizeof(dev_t) = 8; > > this is already true in glibc. > > The fact that glibc is a quivering mass of bloat, and total and utter crap > makes you suggest that the Linux kernel should try to be as similar as > possible? > > Not a very strong argument. > > There is no way in HELL I will ever accept a 64-bit dev_t. > > I _will_ accept a 32-bit dev_t, with 12 bits for major numbers, and 20 > bits for minor numbers. > > If people cannot fit their data in that size, they have some serious > problems. And for people who think that you should have meaningful minor > numbers where the bit patterns get split up some way, I can only say "get > a frigging clue". That's what you have filesystem namespaces for. Don't > try to make binary name-spaces. > > And I don't care one _whit_ about the fact that Ulrich Drepper thinks that > it's a good idea to make things too large. Amen. It's entierly sufficent to take a size similiar to the one on systems which don't have the problems linux has in this area. Our daily motto should be: "Maybe we don't know a shit about OS design - but we known very well up to the ground how Solaris works." Please forgive me If I stressed your sense of humour a bit too much :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Rik van Riel wrote: > > On Sun, 25 Mar 2001, Martin Dalecki wrote: > > > Ah... and of course I think this patch can already go directly > > into the official kernel. The quality of code should permit > > it. I would esp. request Rik van Riel to have a closer look > > at it... > > - the algorithms are just as much black magic as the old ones > - it hasn't been tested in any other workload than your Oracle > server (at least, not that I've heard of) No that's not true! Read the code please. The result is a simple wighted sum without artificial unit. > - the comments are just too rude ;) > (though fun) That's only a matter for the "smooth" anglosaxons. Different cultures have different measures on this. I don't feel the need to adjust myself to the american cultural obstructivity. I esp. to the habit of don't saying clearly what one means if one want's to criticize something. > - the AGE_FACTOR calculation will overflow after the system has > an uptime of just _3_ days > - your code might be good for server loads, but for normal > users it will kill what amounts to a random process ... this > is horribly wrong for desktop systems No that isn't true. I esp. the behaviour will be predictable. > In short, I like some of your ideas, but I really fail to see why > this version of the code would be any better than what we're having > now. In fact, since there seem to be about 1000x more desktop boxes > than Oracle boxes (probably even more), I'd say that the current > algorithm in the kernel is better (since it's right for more systems). You misunderstood me compleatly. I wasn't using an running oracle db as a test case. I was using the INSTALLATION process. Since you apparently don't know about oracle I will tell you: It involves a lot of different applications. Infact TONS of: Java, shell, compiler, linker, apache, perl and whatanot. > Now if you can make something which preserves the heuristics which > serve us so well on desktop boxes and add something that makes it > also work on your Oracle servers, then I'd be interested. I would like to state: The current heuristics DON'T serve us well on desktop boxes... > Alternatively, I also wouldn't mind a completely new algorithm, as > long as it turns out to work well on desktop boxes too. But remember I was testing on a NOTEBOOK. > that we cannot tell this without first testing the thing on a few > dozen (hundreds?) of machines with different workloads... That's true for sure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Alan Cox wrote: > > > That depends what you mean by "must not". If it's your missile guidance > > system, aircraft autopilot or life support system, the system must not run > > out of memory in the first place. If the system breaks down badly, killing > > init and thus panicking (hence rebooting, if the system is set up that > > way) seems the best approach. > > Ultra reliable systems dont contain memory allocators. There are good reasons > for this but the design trade offs are rather hard to make in a real world > environment I esp. they run on CPU's without a stack or what? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Jonathan Morton wrote: > > >- the AGE_FACTOR calculation will overflow after the system has > > an uptime of just _3_ days > > Tsk tsk tsk... > > >Now if you can make something which preserves the heuristics which > >serve us so well on desktop boxes and add something that makes it > >also work on your Oracle servers, then I'd be interested. > > What do people think of my "adjustments" to the existing algorithm? Mostly > it gives extra longevity to low-UID and long-running processes, which to my > mind makes sense for both server and desktop boxen. > > Taking for example an 80Mb process under my adjustments, it is reduced to > under the badness of a new shell process after less than a week's uptime > (compared to several months), especially if it is run as low-UID. Small, > short-lived interactive processes still don't get *too* adversely affected, > but a memory hog with only a few hours' uptime will still get killed with > high probability (pretty much what we want). > > I didn't quite understand Martin's comments about "not normalised" - > presumably this is some mathematical argument, but what does this actually > mean? Not mathematics. It's from physics. Very trivial physics, basic scool indeed. If you try to calculate some weightning factors which involve different units (in this case mostly seconds and bits) then you will have to make sure tha those units get factorized out. Rik is just throwing the absolute values together... Trivial example: "How long does it take to travel from A to B?" "It takes about 1000sec." "How long does it take to travel from C to D?" "It takes about 100sec." "Ah, so it's 10 times longer from A to B then from C to D". Write it down - you just divide the seconds out. In case of varying intervalls you have to normalize measures by max/min values. Since for example the amount of RAM in a box can vary as well. Otherwise your algorithms will behave very differently on boxes with low RAM in comparision to boxes with huge amounts of it. That's what one says if he talks about an algorithm "scalling well". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 64-bit block sizes on 32-bit systems
"Eric W. Biederman" wrote: > > Matthew Wilcox <[EMAIL PROTECTED]> writes: > > > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote: > > > What do you mean by problems 5 years down the road? The real issue is that > > > this 32-bit block count limit affects composite devices like MD RAID and > > > LVM today, not just individual disks. There have been several postings > > > I have seen with people having a problem _today_ with a 2TB limit on > > > devices. > > > > people who can afford 2TB of disc can afford to buy a 64-bit processor. > > Currently that doesn't solve the problem as block_nr is held in an int. > And as gcc compiles an int to a 32bit number on a 64bit processor, the > problem still isn't solved. > > That at least we need to address. And then you must face the fact that there may be the need for some of the shelf software, which isn't well supported on correspondig 64 bit architectures... as well. So the arguemnt doesn't hold up to the reality in any way. BTW. For many reasons 32 bit architecutres are in respoect of some application shemes *faster* the 64. Ultra III in 64 mode just crawls in comparision to 32. Alpha - unfortulatly an orphaned and dyring archtecutre... which is not well supported by sw verndors... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer???
Jonathan Morton wrote: > > >Out of Memory: Killed process 117 (sendmail). > > > >What we did to run it out of memory, I don't know. But I do know that > >it shouldn't be killing one process more than once... (the process > >should not exist after one try...) > > This is a known bug in the Out-of-Memory handler, where it does not count the buffer >and cache memory as "free" (it should), causing premature OOM killing. It is, >however, normal for the OOM killer to attempt to kill a process more than once - it >takes a few scheduler cycles for the SIGKILL to actually reach the process and take >effect. > > Also, it probably shouldn't have killed Sendmail, since that is usually a >long-running, low-UID (and important) process. The OOM-kill selector is another >thing that wants fixing, and my patch contains a *very rough* beginning to this. > > The following patch should solve your problem for now, until a more detailed fix >(which also clears up many other problems) is available in the stable kernel. > > Alan and/or Linus may wish to apply this patch too... > > (excerpt from my original patch from Saturday follows) > > --- start --- > diff -u linux-2.4.1.orig/mm/oom_kill.c linux/mm/oom_kill.c > --- linux-2.4.1.orig/mm/oom_kill.c Tue Nov 14 18:56:46 2000 > +++ linux/mm/oom_kill.c Sat Mar 24 20:35:20 2001 > @@ -76,7 +76,9 @@ > run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10); > > points /= int_sqrt(cpu_time); > - points /= int_sqrt(int_sqrt(run_time)); > + > + /* Long-running processes are *very* important, so don't take the 4th root */ > + points /= run_time; > > /* > * Niced processes are most likely less important, so double > @@ -93,6 +95,10 @@ > p->uid == 0 || p->euid == 0) > points /= 4; > > + /* Much the same goes for processes with low UIDs */ > + if(p->uid < 100 || p->euid < 100) > + points /= 2; > + Plase change to 100 to 500 - this would make it consistant with the useradd command, which starts adding new users at the UID 500 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Michel Wilson wrote: > > > relative ages. The major flaw in my code is that a sufficiently > > long-lived > > process becomes virtually immortal, even if it happens to spring a serious > > leak after this time - the flaw in yours is that system processes > > I think this could easily be fixed if you'd 'chop off' the runtime at a > certain point: > > if(runtime > something_big) > runtime = something_big; > > This would of course need some tuning. The only thing i don't like about > this is that it's a kind of 'magical value', but i suppose it's not a very > good idea to make this configurable, right? Then after some time runtime becomes allmost irrelevant. You are basically for what I call normalization by the total system uptime. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Jonathan Morton wrote: > > Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for > "badness". Think about it - it increases with pigginess and decreases with > longevity. I really don't see a problem with it per se. Right it's not a problem pre se, but as you already explained the problem is in the weightinig of different factors. It's a matter of principle. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer???
Ingo Oeser wrote: > > On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote: > > > @@ -93,6 +95,10 @@ > > > p->uid == 0 || p->euid == 0) > > > points /= 4; > > > > > > + /* Much the same goes for processes with low UIDs */ > > > + if(p->uid < 100 || p->euid < 100) > > > + points /= 2; > > > + > > > > Plase change to 100 to 500 - this would make it consistant with > > the useradd command, which starts adding new users at the UID 500 > > No, useradd reads usally the /etc/login.defs to select the range. > The oom-killer should have configurables for that, to allow the > policy decisions in USER space -- where it belongs -- not in KERNEL space OK sysctl would be more appripriate. > If we use my OOM killer API, this patch would be a module and > could have module parameters to select that. > > Johnathan: I URGE you to apply my patch before adding OOM killer >stuff. What's wrong with it, that you cannot use it? ;-) > > It is easy to add configurables to a module and play with them > WITHOUT recompiling. It's total overkill and therefore not a good design. > Dynamic sysctl tables would also be possible, IF we had an value > that is DEFINED to be invalid for sysctrl(2) and only valid for /proc. > > It is also better to include the egid into the decision. There > are deamons, that I defintely want to be killed on a workstation, > but not on a server. > > e.g. My important matlab calculation, which runs in user mode > should not be killed. But killing a local webserver, which serves > my help system is ok (because I will not loose work, and might > get it over the net, if there is a problem). > > So as Rik stated: The OOM killer cannot suit all people, so it > has to be configurable, to be OOM kill, not overkill ;-) Irony: Why then not store this information permanently - inside the UID of the application? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
"H. Peter Anvin" wrote: > > This is my opinion on the issue. Short summary: "I'm sick of the > administrative burden associated with keeping dev_t dense." > > Linus Torvalds wrote: > > > > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every > > device needs a unique number. Do you ever envision seeing that "ls -l" > > taking about 500 billion years to complete? I don't. I don't think you do. > > But that's how ludicrous a 64-bit device number is. > > > > That's how ludicrous a *dense* 64-bit device number is. I have to say I > disagree with you that sparse number spaces are a bad idea. The > IPv4->IPv6 transition people have looked at the issues of number spaces > and how much harder they get to keep dense when the size of the > numberspace grows, because your lookup operation becomes so much more > painful. Any time you have to take a larger number space and squeeze it > into a smaller number space, you get some serious pain. > > Part of the reason we haven't -- quite -- run out of 8-bit majors yet is > because I have been an absolute *bastard* with registrants lately. It > would cut down on my workload if I could assign majors without worrying > too much about whether or not that particular driver is really going to > be made public. > > 64 bits is obviously excessive, but I really don't feel comfortable > saying that only 12 bits of major is sufficient. 16 I would buy, but I > don't think 16 bits of minor is sufficient. Given that, it seems to me > -- especially since dev_t isn't exactly the most accessed data type in > the universe -- that the conceptual simplicity of keeping the major and > minor separate in individual 32-bit words really is just as well. YES, > it's overengineering, but the cost is very small; the cost of > underengineering is having to go through yet another painful transition. > Unfortunately, the Linux community seems to have some serious problems > with getting system-wide transitions to happen, especially the ones that > involve ABI changes. This needs to be taken into account. > > -hpa Then just tell me please why the PCI name space is just 32 bit? Majros are for drivers Minors are for device driver instances (yes linux does split minors in a stiupid way by forexample using the same major for IDE disks and ide CD-ROM, which are in fact compleatly different devices just sharing driver code... (Dirrerent block sizes, different interface protokoll and so on) Those are the reaons solaris is using a split 24/12 (Major/Minor) and they don't have our problems here. > > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
"H. Peter Anvin" wrote: > > Alan Cox wrote: > > > > > Another example: all the stupid pseudo-SCSI drivers that got their own > > > major numbers, and wanted their very own names in /dev. They are BAD for > > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d] > > > and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI > > > > Sorry here I have to disagree. This is _policy_ and does not belong in the > > kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of > > major/minor encoding. If you dont mind kernel based policy then devfs > > with /dev/disc already sorts this out nicely. > > > > IMHO more procfs crud is also not the answer. procfs is already poorly > > managed with arbitary and semi-random namespace. Its a beautiful example of > > why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's > > per device file systems solve that. > > > > In some ways, they make matters worse -- now you have to effectively keep > a device list in /etc/fstab. Not exactly user friendly. > > devfs -- in the abstract -- really isn't that bad of an idea; after all, Devfs is from a desing point of view the duplication for the bad /proc design for devices. If you need a good design for general device handling with names - network interfaces are the thing too look at. mount() should be more like a select()... accept()! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox wrote: > > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not > > hogging a major number, but letting low-level drivers get at _their_ > > requests directly. > > A major for 'disk' generically makes total sense. Classing raid controllers > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also > solve a lot of misery And IDE disk ver CD-ROM f and block vers. raw devices and so so at perpetuum. Those are the reaons why the density of majros ver. minors is exactly revers in solaris with respect to the proposal of Linus.. And then we have all those VERY SPARSE static arrays of major versus minor devices information (if you look at which cells from those arrays are used on a running system which maybe about 6-8 devices actually attached!) The main sheer practical problem to changing kdev_t is the HUGE number of in fact entierly differnt drivers sharing the same major and splitting up the minor number space and then hooking devices with differnt block sizes and such on the same major. Many things in the block device layer handling could be simplefied significalty if one could assume for example that all the devices on one single major have the same block size and so on... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Linus Torvalds wrote: > > On Tue, 27 Mar 2001, Andre Hedrick wrote: > > > > Am I hearing you state you want dynamic device points and dynamic majors? > > Yes and no. > > We need static structures for user space - from a user perspective it > makes a ton more sense to say "I want to see all disks" than it does to > know that you have to do /dev/hd*, /dev/sd* plus all the extra magic > combinations that can happen (USB etc). > > So in a sense what I'm arguing for is for _stricter_ device numbers to the > outside world. > > But internally, it would be reasonably easy to make a mapping from those > user-visible numbers to a much looser version. > > One example of this is going to happen very early in 2.5.x: the whole > "partitioning" stuff is going to go away from the driver, and into the > ll_rw_block layer as just another disk re-mapping thing. We already do > those kinds of re-mappings for LVM reasons anyway, and partitioning is not > something a disk driver should know about, really. > > And that kind of partitioning mapping automatically means that we'd need > to remap minor numbers, and do it on a per-major basis (because the > partitioning mapping right now is not actually the same between SCSI and > IDE: IDE uses six bits of partitioning, while SCSI uses just four bits). > And once you do that, you might as well start "remapping" major numbers > too. > > So let's say that you have two separate SCSI controllers - they would both > show up on major #8, and different minor numbers. Right now, for example, > controller 1 might have one disk, with minors 0-15 (for the whole disk and > 15 partitions), and controller 2 might have two disks using minors 16-47. > > As it stands now, the SCSI layer needs to do the remapping, and because > the SCSI layer does the remapping, nothing but SCSI layer devices can use > major #8. > > But once you start doing partition mapping in ll_rw_block.c, you might as > well get rid of the notion that "SCSI is major 8". You could easily have > many different drivers, with many different queues, and remap them all to > have major 8 (and different minors) so that it looks simple for a user > that just wants to see SCSI disks. > > Which is not to say that the same disk might not show up somewhere else > too, if anybody wants it to. The _driver_ should just know "unit x on > queue y", and then the driver might do whatever it wants (it might be, for > example, that the driver actually wants to show multiple controllers as > one queue, if the driver really wants to for some reason). And it should > be possible to have two drivers that really have no idea at ALL about each > other to just share the same major numbers. Then please please please demangle other cases as well! IDE is the one which is badging my head most. SCSI as well... Granted I wouldn't mind a rebot with new /dev/* once! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
> what do other vaguely unix-like systems do? does, say, plan9 have a > better way of dealing with all this? Yes. Normal UNIX has as well. For reffernece see: block ver raw devices on docs.sun.com :-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox wrote: > > > Exactly. It's just that for historical reasons, I think the major for > > "disk" should be either the old IDE or SCSI one, which just can show more > > devices. That way old installers etc work without having to suddenly start > > knowing about /dev/disk0. > > They will mostly break. Installers tend to parse /proc/scsi and have fairly > complex ioctl based relationships based on knowing ide v scsi. > > /dev/disc/ is a little un-unix but its clean Why do you worry about installers? New distro - new kernel - new installer that's they job to worry about it. They will change the installer anyway and this kind of change actually is going to simplyfy the code there, I think, a bit. Just kill the old device major suddenly and place it in the changelog of the new kernel that the user should mknod and add it to /dev/fstab before rebooting into the new kernel. Hey that's developement anyway :-) If the developer boots back into the old kernel just other mounts in /dev/fstab will fail no problem for transition here in sight... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox wrote: > > > Why do you worry about installers? New distro - new kernel - new > > installer > > Because the same code tends to be shared with post install configuration > tools too. So change them as well for a new distribution. What's there problem. There isn't anything out there you can't do by hand. Fortunately so! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait
Linus Torvalds wrote: > > On Tue, 6 Feb 2001, Ben LaHaise wrote: > > > > On Tue, 6 Feb 2001, Stephen C. Tweedie wrote: > > > > > The whole point of the post was that it is merging, not splitting, > > > which is troublesome. How are you going to merge requests without > > > having chains of scatter-gather entities each with their own > > > completion callbacks? > > > > Let me just emphasize what Stephen is pointing out: if requests are > > properly merged at higher layers, then merging is neither required nor > > desired. > > I will claim that you CANNOT merge at higher levels and get good > performance. > > Sure, you can do read-ahead, and try to get big merges that way at a high > level. Good for you. > > But you'll have a bitch of a time trying to merge multiple > threads/processes reading from the same area on disk at roughly the same > time. Your higher levels won't even _know_ that there is merging to be > done until the IO requests hit the wall in waiting for the disk. Merging is a hardware tighted optimization, so it should happen, there we you really have full "knowlendge" and controll of the hardware -> namely the device driver. > Qutie frankly, this whole discussion sounds worthless. We have solved this > problem already: it's called a "buffer head". Deceptively simple at higher > levels, and lower levels can easily merge them together into chains and do > fancy scatter-gather structures of them that can be dynamically extended > at any time. > > The buffer heads together with "struct request" do a hell of a lot more > than just a simple scatter-gather: it's able to create ordered lists of > independent sg-events, together with full call-backs etc. They are > low-cost, fairly efficient, and they have worked beautifully for years. > > The fact that kiobufs can't be made to do the same thing is somebody elses > problem. I _know_ that merging has to happen late, and if others are > hitting their heads against this issue until they turn silly, then that's > their problem. You'll eventually learn, or you'll hit your heads into a > pulp. Amen. -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait
Linus Torvalds wrote: > > On Thu, 8 Feb 2001, Rik van Riel wrote: > > > On Thu, 8 Feb 2001, Mikulas Patocka wrote: > > > > > > > You need aio_open. > > > > Could you explain this? > > > > > > If the server is sending many small files, disk spends huge > > > amount time walking directory tree and seeking to inodes. Maybe > > > opening the file is even slower than reading it > > > > Not if you have a big enough inode_cache and dentry_cache. > > > > OTOH ... if you have enough memory the whole async IO argument > > is moot anyway because all your files will be in memory too. > > Note that this _is_ an important point. > > You should never _ever_ think about pure IO speed as the most important > thing. Even if you get absolutely perfect IO streaming off the fastest > disk you can find, I will beat you every single time with a cached setup > that doesn't need to do IO at all. > > 90% of the VFS layer is all about caching, and trying to avoid IO. Of the > rest, about 9% is about trying to avoid even calling down to the low-level > filesystem, because it's faster if we can handle it at a high level > without any need to even worry about issues like physical disk addresses. > Even if those addresses are cached. > > The remaining 1% is about actually getting the IO done. At that point we > end up throwing our hands in the air and saying "ok, this will be slow". > > So if you design your system for disk load, you are missing a big portion > of the picture. > > There are cases where IO really matter. The most notable one being > databases, certainly _not_ web or ftp servers. For web- or ftp-servers you > buy more memory if you want high performance, and you tend to be limited > by the network speed anyway (if you have multiple gigabit networks and > network speed isn't an issue, then I can also tell you that buying a few > gigabyte of RAM isn't an issue, because you are obviously working for > something like the DoD and have very little regard for the cost of the > thing ;) > > For databases (and for file servers that you want to be robust over a > crash), IO throughput is an issue mainly because you need to put the damn > requests in stable memory somewhere. Which tends to mean that _write_ > speed is what really matters, because the reads you can still try to cache > as efficiently as humanly possible (and the issue of database design then > turns into trying to find every single piece of locality you can, so that > the read caching works as well as possible). > > Short and sweet: "aio_open()" is basically never supposed to be an issue. > If it is, you've misdesigned something, or you're trying too damn hard to > single-thread everything (and "hiding" the threading that _does_ happen by > just calling it "AIO" instead - lying to yourself, in short). Right - I agree with you that an AIO design is basically hiding an inherently multi threaded program flow. This argument is indeed very catchy. And looking from some other point one will see that most of the AIO designs are from times where multi threading in applications wasn't that common as it is now. Most prominently coprocesses in a shell come to my mind as a very good example about how to handle AIO (sort of)... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote: > > > They are entirely different. Too different sets of operations. > > Maybe you didnt understand what I meant. > both bdev and cdev take care of the correspondence > device number <---> struct with operations. > > The operations are different, but all bdev/cdev code is identical. > > So the choice is between two uglies: > (i) have some not entirely trivial amount of code twice in the kernel > (ii) have a union at the point where the struct operations > is assigned. > > I preferred the union. > > >> And a second remark: don't forget that presently the point where > >> bdev is introduced is not quite right. We must only introduce it > >> when we really have a device, not when there only is a device > >> number (like on a mknod call). > > > That's simply wrong. kdev_t is used for unopened objects quite often. > > Yes, but that was my design mistake in 1995. I fully agree with you. Most of the places where there kernel is passing kdev_t would be entierly satisfied with only the knowlendge of the minor number used to distinguish between different device ranges, which is BTW an abuse by itself as well since minors where for encounters of instances of similiar devices in linux... The places where this is the case are namely: 1. literally: all character devices. 2. The whole scsi stuff. 3. most of the ide stuff. 4. md/lvm and similiar culprits. I did "discover" this by splitting the i_dev field from stuct inode into explicit i_minor and i_major fields and then actually "fixing" my particular kernel configuration until it worked again. This was *very* insigtfull, since it discovered all the places where kdev_t get's used, where it shouldn't be of any need anylonger anyway. The remaining places where kdev_t comes into sight are mostly the places where the kernel is mounting the initial root device. In case you would like to have a look at the resulting bit huge patch I can send it to you... > I think you'll find if you continue on this way, > as I found and already wrote in kdev_t.h > that it is bad to carry pointers around for unopened and unknown devices. > > So, I think that the setup must be changed a tiny little bit > and distinguish meaningless numbers from devices. > > Andries > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote: > > Martin Dalecki writes: > > > I fully agree with you. > > Good. > > Unfortunately I do not fully agree with you. > > > Most of the places where there kernel is passing kdev_t > > would be entierly satisfied with only the knowlendge of > > the minor number. > > My kdev_t is a pointer to a structure with device data > and device operations. Among the operations a routine > that produces a name. Among the data, in the case of a > block device, the size, and the sectorsize, .. > > A minor gives no name, and no data. > > Linus' minor is 20-bit if I recall correctly. > My minor is 32-bit. Neither of the two can be > used to index arrays. Erm... I wasn't talking about the DESIRED state of affairs! I was talking about the CURRENT state of affairs. OK? The fact still remains that most of the places which a have pointed out just need the minor nibble of whatever bits you pass to them. Apparently nobody on this list here blabbering about a new improved minor/major space didn't actually take the time and looked into all those places where the kernel is CURRENTLY replying in minor/major array enumeration. They are TON's of them. The most ugly are RAID drivers an all those MD LVW and whatever stuff as well as abused minor number spaces as replacements of differnt majors. At least you have admitted that you where the one responsible for the design of this MESS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
