I reckon a spare CPU could happily

• pre-zero some pages, preferably spread over the range of page colours.
• move pages around to make space for multi-page allocations.
• checksum pages to find duplicates and merge them in the background

there's a good paper related to this published in the OSDI '99 proceedings. see:

Chang, F., Gibson, G., "Automatic I/O Hint Generation through Speculative Execution," Proceedings of the Third Symposium on Operating Systems Design and Implementation, pp. 1-14, February 1999.

the authors used speculative execution during I/O waits to predict future read requests instead of the method you described. their conclusion was that were good gains from speculative execution, but the technique requires significant O/S complexity.

Yes, they are kind enough to supply you with the address of the code that will allow them to sell you a UPS. What they don't tell you was that they threatened Andre with legal action for his code, which caused a BIG rift on this mailing list last year (Oct-Nov 98). Despite the company trying to squash Andre's program, they surely didn't mind making money off selling UPS's and pointing out Andre's program's existence.

Finally after much discussion with APC, etc... Andre released the code back under GPL basically to "call their bluff" around April 7th I believe. They realized they had no legal footing and as far as I know they just shut up.

They are NOT a Linux friendly company however - despite what they may say on the phone. They'll say whatever you want to hear if you'll buy one of their products.

That would be even harder to accomplish as you'd have to change page tables upon entering any exception handlers, copy_*_user would have to be kludged around... Not the sort of messiness likely to ever make it into the mainstream kernel (and less likely to be developed). The general consensus that keeps coming up is that if your needs are that great, you'd probably be better served by a 64 bit architecture where the fixes are much simpler (ie dealing with 32 bit pci dma issues).

The 36 bit support for ia32 should allow for something close to what you want -- it would be possible to make kernel address space smaller, reducing memory for caching, but increasing the virtual address space which could be filled with high memory.

I think you must be mistaken; by default Linux supports 3GB of virtual memory and 1GB (- epsilon = 960MB, iirc) of physical RAM. It's possible to change that to 2GB + 2GB, but it isn't possible to get 4GB of linear addressed space on x86. If you need that, get an Alpha.

Even the proposed 36-bit extensions won't allow this -- they merely allow the system to keep around many more anonymous pages which you can't use directly. Fortunately, this is exactly what big databases want.

The user-mode kernel is now a 2.3.12 kernel, and I plan to keep it current with the latest development kernels. It is now possible to log in on the console, and there were also some improvements made to the serial line. All the details are available at http://www.mv.com/ipusers/karaya/uml/uml.html.

Below is a patch to ptrace that I would like to get into 2.3. It allows ptrace to change system call numbers. I need it for the user-mode kernel, and Michael Elizabeth Chastain needs it for his trace-and-replay debugger. I'd appreciate it if people would look at it and let me know about any problems.

Feature freeze in about two weeks is the current plan.

In short, people who think they have major requirements had better get their act together. That means that if ISDN people actually want to try to get into a real release one of these years, they don't have all that much time to futz around any more.

And it does mean that if it's not in working order already, it probably won't make it into 2.4.

I have a 2.3.12 running with the current isdn4linux cvs tree. I will get crasy if my work again will not find the way into the main stream kernel.

Why is it a problem to put this stuff into the kernel ?

What is the actual way to put changes into the actual kernel for isdn4linux? What can I do to fix that problems ? Should I sent a patch to 2.3.12 to you or someone else ?

I don't know why the ISDN people just do not ever GET IT.

I refuse to get huge patches every time two weeks before a feature freeze. How hard is that to understand?

I will continue to ignore the ISDN CVS tree. If the ISDN people cannot get their act together and actually start sending their fixes to the standard kernel in a timely manner, I cannot be bothered with it. This has continued for something like five years now, and every time I explain it to people my explanation gets lost or ignored.

It's not about sending "a patch".

It's about being a responsible programmer, and making sure I get MORE than just a patch every f*cing time I anounce a code freeze. I should have been getting patches for the last half year, and I have gotten ZERO. And I'm irritated at the ISDN peopl, because this is not the first time. In fact, I have never EVER gotten a single responsible ISDN developer that stands up and says "ok, I'll be the maintainer of this, and I'll make sure it gets fed to Linus in a timely manner".

You still wonder why ISDN is not there? Do you still wonder why I'm fed up with ISDN people who think they they can just force-feed me one huge patch and completely avoid any QA in the meantime?

WHY, oh why, is the ONLY time I ever hear from ISDN people when I have publically announced a code-freeze? Explain that.

Oh, I agree. That much is obvious. In fact, I've accepted some of them over time.

The reason I'm bitching is not just because I love biting peoples heads off in public, it's because I do not want to see the ISDN incompetence continue. I want people to be aware of the problem, and I want somebody to stand up and say "I'll do it".

I can accept large patches initially, but I want to do so in the solid knowledge that it's the last time EVER I have to wait for ISDN code until the last moment. There's obviously no way we can fix past problems, I just do not want them to repeat every single release cycle like they have so far.

It needs to be more than one person agreeing, but yes, I'd love to have a contact person. You need to make the other ISDN developers accept you as more than just the person who forwards patches to Linus. The problem is that sometimes I do not like a patch, and then there needs to be some kind of feedback cycle. It doesn't happen all that often when it comes to drivers (I just don't care enough - I mainly care about the fundamental interactions in the system rather than specific drivers), but it does happen.

I would certainly =love= to not have to hate ISDN support.

It's not getting any peer review, nobody looks at incremental patches, and nobody really seems to care.

In short, the ISDN code in Linux acts as if it was a traditional code project where the users might as well just have binaries.

The point of open development is that people see what's going on. You don't get that if people see just the end result after a year. You want to have random people just see small updates - because they will often catch silly mistakes.

Now, with huge mega-patches, people just go numb. They say "oh, an ISDN update", and skip it.

With the regular "let's release this as it is developed" support, there have been web-sites with commented patches, people who read the incremental stuff and comment on stupid things I and others do. No, it doesn't happen all the time, but it does happen. ISDN for Linux lacks that completely, and acts as a closed development environment.

Common mistake: peer review does NOT mean that the code should be looked at by the same people who write it.

Peer review is _meaningless_ under those circumstances. The whole point of getting peer review is to find _different_ people who have a different background to look at your code.

[ Irritated mode: FULL BLAST ]

Are you being stupid on purpose, or were you born that way?

Go back and read the thread. Read why I'm irritated. READ. THINK.

[ Irritated mode: NORMAL ]

I'm really disgusted with ISDN development. I'm disgusted with the fact that I don't _ever_ see any development until after code freeze announcements, which is at a point where it is basically too late.

I'm used to that happening. It happens with other drivers too. The thing that makes ISDN stand out is that with other drivers it happens ONCE.

With ISDN, it has happened EVERY SINGLE DAMN RELEASE TIME! For the last FIVE years or so. I've complained before, and every time my complaints are apparently ignored, and result in stupid comments like the above.

It is over. I refuse to see this continue. The ISDN people need to open up, and stop the ridiculous practice of having closed lists and closed releases, and not feeding them back until it's basically too late. The ISDN people need to get on with the program, because it doesn't work the way it is handled now.

We had this exact discussion during the 2.2.x release thing, and yet people seem to not have woken up. I don't know what I have to do to make people understand. I'm considering asking SuSE to stop funding any development that doesn't find its way in a timely manner into the standard kernel, for example.

I know there _are_ people at SuSE who understand that the current ISDN development model is a disaster for releases. Maybe you should talk to them.

Not really true.

It's true in Germany, not in many other places. Germany is one of the few countries in the world who still have a rather strong monopoly on phones, although it finally seems to be crumbling there too, as even the Germans are growing tired of bad service and exorbitant fees ;)

And even in Germany, it's only true of drivers that do everything in software: most modern ISDN cards have the actual connection smarts in firmware and do not need the same certification (well, they do, but not on the OS driver side: now it's a hardware certification issue). So only a rather small subset of the ISDN code is actually affected by these rules, and its' fairly easy to say something like "for these cards, it is illegal to connect the machine to the phone line if this part of the code has been changed".

I think it's basically just one or two drivers, and a subset of the driver at that.

And quite frankly, let the people vote with their feet. Civil disobedience is not always a bad thing, as shown by people like Gandhi. Bringing down bad phone monopolies may not ever count as highly as getting the British Empire out of India, but let people decide on their own whether they should just bend over and take bad rules.

So, what do you suggest to remedy the situation? The ISDN updates are dearly needed by the masses, your argument (which I completely agree with) with the ISDN developers non withstanding.

What about if you both get over it: You _once_ accept the big patch so we can resolve the situation right now, and the i4ldevelopers promise to feed you smaller patches in the future so it never occurs again.

For 2.2.x we don't have much choice - either it dosn't get updated at all, or it gets updated in one large fell swoop.

For 2.3.x the choices are also fairly limited. Most of them basically involve one large initial sync patch, and then future patches in a more timely fashion. I don't think we can synch up reasonably any other way, although it might be nice to have the initial larger sync be done on a per-driver basis at least to some degree.

The thing is, that before I accept the large sync, I really want to get the issues out in the open, and I really do want to make sure that when the 2.5.x development tree opens, the ISDN code won't be in the same shape as it is now, with large pending patches.

For example, I really want ISDN developers to try to be as disciplined as other devlopers are during a feature freeze. Instead of thinking "Oh, the standard kernel has a feature freeze, so we'll just do all our development in the CVS tree and sych up in one large go", the ISDN people too should understand what the feature freeze is all about: testing a stable system, and making sure that the bugs at that time get ironed out and _nothing_ else. No secret CVS tree activity on the side etc. It's about hammering something out that you can live with for a year or two there-after WITHOUT telling people to upgrade to some completely new CVS tree version.

Now, "disciplined as the other developers" is probably an oxymoron. None of the Linux feature- or code-freezes have been all THAT disciplined, but at least people tried, and we basically succeeded reasonably well in the end.

And remember: feature-freeze and even code-freeze does not mean that bugs don't get fixed, it just means that people really ONLY concentrate on finding the bugs. It should be something ISDN developers need to do occasionally too, and this all really shouldn't be all that big of an issue. It's just that historically it has really not worked at all..

Run this on the client in a separate window:

        while usleep 100000; do ls notfound; done

Go to the server and create the "notfound" file. The client script will never see this file due to caching. When the usleep is increased towards 1 second then the file will be found in most cases

I've been meaning to fix this, the way to really do it is:

1. Never require that a slab gets destroyed. Even after the module unloads, the cache will be shrunk naturally as the system trims SLAB caches all the time when memory gets tight.
2. Have kmem_cache_create copy the string over into a new buffer, so the reference to the string in the module doesn't exist. In fact make kmem_cache_t->name[64] or whatever so that it will still work while SLAB is setting itself up.
3. Have kmem_cache_create check to see if the slab exists already, by comparing the name and the parameters. If they match, just return the old slab cache pointer, don't make a new one.

This will solve all the problems in one go, and localize the changes to one spot.

Guys I implemented kmem_cache_destroy() long ago!! I posted a patch alone with explanation plus testing and testing kernel module as well!! Since it's been _ignored_ by _everybody_ out there (even from people like AV who asked for it) it stayed long time into my 2.2.x andrea-patches (as tons of other good stuff!!).

Luckily at that time I did a directory in my ftp area (unlike for the other good stuff). I am pretty sure the patch will apply cleanly on 2.3.x as well since the slab is been unchanged over the time.

        ftp://ftp.suse.com/pub/people/andrea/slab/slab-destroy-2.2.2
        ftp://ftp.suse.com/pub/people/andrea/slab/slab-test-0.tar.gz

andrea@penguin:/home/ftp/pub/andrea/slab$ ls -l
total 9
-rw-r--r--   1 andrea   andrea       6222 Feb 25 20:31 slab-destroy-2.2.2
                                          ^^^^^^
-rw-r--r--   1 andrea   andrea       1823 Feb 25 20:33 slab-test-0.tar.gz
                                          ^^^^^^

Please apply it!! (if you want a detailed description of the patch browse linux-kernel of february or ask me to browse linux-kernel and forward you my original email of february).

I've uploaded the 2.2.11pre6->7 patch to ftp.kernel.org:/pub/linux/kernel/alan

This one contains:

• Second set of merges from DaveM
• Alpha compile fix
• SIS 900 PCI ethernet driver

This should mean 2.2.11pre7 is the final ready for 2.2.11. I've got various other patches from people queued because I want them to be in 2.2.12 so that 2.2.11 doesn't get too many non driver changes.

Please test this one hard folks.