Gregory Finch reported good success with the recent real-time scheduling patch, even under SMP, which the patch had not been entirely intended for. Robert Love was very happy to hear about the SMP part, and added:
You can run some of the tests made especially for testing latency, like an audio benchmark. One such test is at http://www.gardena.net/benno/linux/latencytest-0.42.tar.gz
Obviously a heavily tasked I/O benchmark is useful, I have used dbench in the past (ftp://samba.org/pub/tridge/dbench/) (try it with 16 processes or so), but I have been told I should use bonnie.
You can time normal things, too. `time make dep clean bzImage' is always a favorite :)
Under UP, enabling preemption helps all of this (the recent linuxdevices article on preemption shows a 30x decrease in latency.). Both myself and Nigel have run dbench with good results for -16. See http://kpreempt.sourceforge.net/ for some more.
Some other folks did have problems with the patch, however, and there was a lively hunt for various problems.
Peter Magnusson didn't like the behavior of the virtual memory subsystem in recent kernels, and listed off a few versions with his corresponding assessment of their performance. Linus Torvalds pointed out that for several of those versions there hadn't been any VM changes; he guess that Peter had simply run different loads and had different experiences due to that. Tonu Samuel felt that there were definitely performance problems with the VM in recent kernels. Andrea Arcangeli replied:
After a few days of developement I think I'm ready to release the VM rewrite I did.
The alternate vm will be included in 2.4.10pre9aa1 (or anwways the very next -aa release) and I'll maintain it in the -aa tree. It is supposed to provide:
- stable kswapd, avoid the kswapd 100% load of the cpu problem (this is provided by the classzone design, btw I improved the implementation a little bit compared to the 2.3/2.4.0-test patches, now I try to do things as lazily as possible without the bookkeeping in the pagealloc/pagefreeing)
- optimal performance, avoid slowdowns after multiple runs of workloads and avoid swapout storms (for databases not using O_DIRECT)
- you will get swap+ram of available virtual memory
At the moment it's of course still a bit experimental and subject to changes but I'm writing this email on top of it and it's perfectly usable.
This isn't an hack/band-aid or a small set of changes, it's a complete rewrite from scratch of the whole memory balancing including garbage collections lru lists, kswapd etc...
Rik van Riel said, I doubt you'll be able to
achieve all of those without really major changes, but I'll take a look
at your code when you make it public ;)
And Alan Cox said, Andrea made 2.2 finally stable under really high VM loads. I'm
certainly interested to see what comes out of this.
Rik replied,
Definately, I have no doubt he'll achieve some
good results. It's the overly wild claims I'm having doubts about.
Nearby, Andrea said, as said it is quite a major
change, it discards most of the the 2.4 vm that I don't agree with, it is
basically an evolution of the classzone patch.
And Linus replied:
That is the wrong direction to go into.
We'll be completely screwed on NuMA with the classzone patch. I've said so before, I'll say so again.
The basic approach of the classzone patch is _wrong_, in making global decisions where no "globality" exists.
I bet that the improvements are from other things, not from classzone itself. And I will bet that if we start doing classzones, we'll regret it a LOT in a few years.
Elsewhere, in a completely different part of the discussion, Stephan von
Krawczynski mentioned to Linus, I tried
Andrea's brand new patch and have to admit it has a _big_ performance gain,
though I understand you dislike the design very much.
Linus replied,
I only dislike one aspect of it, not the whole
patch. Andrea has spent a lot of time doing tuning, which is hugely important
for real-world workloads. I also suspect from previous patches that he
increases read-ahead aggressively etc.
He said he'd take a look at
Andrea's patch.
Jens Axboe announced a patch that allows direct
I/O to highmem memory without resorting to bouncing to lower memory.
Linus Torvalds asked, Jens, what's your feeling
about the stability of these things, especially wrt weird drivers? Ie do you
think this is really a 2.4.x thing, or early 2.5.x?
David S. Miller
replied, On my side of this work I feel that
the 64-bit PCI dma infrastructure by itself is a safe merge in 2.4.11 or
something like that.
Jens also replied to Linus, One of the very first decisions I made wrt this patch was to make sure
that weird/old drivers could keep on working exactly the way they do now and
never have to worry about highmem stuff. That basically means enabling the
stuff on a per-driver basis after it's considered safe.
[...] Most of it is really a cautious back port of the 2.5 stuff
I've been working on, and with the above considerations it is/was meant as
a 2.4 thing :-)
Alan Cox remarked, So better
deferred until 2.5, tried in 2.5 and backported to 2.4 IMHO
. Jens
replied, Maybe. At least the first thing I would like
is for the pci64 patch to be merged in 2.4. That should be very doable without
risking breakage. When that is done it's easier to see what the block-highmem
patch does. And I believe that we _can_ merge it in 2.4 without a 2.5 trial,
it's really not that intrusive.
Arjan van de Ven reported breakage in megaraid with Jens' patch applied.
Although the problem was actually with the megaraid driver, Alan considered
this to be Yet more evidence that it belongs in 2.5
first. Auditing every scsi driver for that error (and I bet someone had it
first and it was copied..)is a big job.
Linus Torvalds announced 2.4.10-pre11:
Ok, the big thing here is continued merging, this time with Andrea.
I still don't like some of the VM changes, but integrating Andrea's VM changes results in (a) better performance and (b) much cleaner inactive page handling in particular. Besides, for the 2.4.x tree, the big priority is stability, we can re-address my other concerns during 2.5.x.
This also merges the blkdev in page cache patch, and that will hopefully make it noticeably easier to do the "do bread() with page cache too", at which point a lot of the current ugly synchronization issues will go away.
Oh, and it gets the direct-IO improvements from Andrea too.
[ Other small patches from Andrea merged just to make future merges easier. ]
The console locking merge with Andrew Morton also moves us a bit closer to the -ac tree..
In the course of discussion, Marcelo Tosatti pleaded:
Andrea,
Personally I think it is too late in the 2.4.x series to integrate your code.
I have nothing against the code itself (the "old" code also had bugs), but a major VM rewrite at this point seems to be dangerous if we want a stable VM.
Don't you agree that your code can introduce new stability bugs ?
Linus, please, if you want to integrate Andrea's code do it in 2.5.x, but not 2.4.x. (yes, I'm expecting you to scream at me now :))
There was no direct reply, but Andrea indicated that he thought his patch
was better than the previous code. Elsewhere, Benjamin LaHaise was also
critical of adding in such an invasive change so late in the 2.4 series. He
complained, The code in question does not
attempt to explain itself at all. Your release notes did not explain what
changes you did at all. Nor are your patches split up into reasonable chunks
of functionality that can be evaluated based on their individual merit.
All or nothing is *not* the approach that should be taken at present. (Hint,
stability is acheived gradually.)
Linus replied, Actually, many of them _are_ split up, much more so than Alan's
public patches are (now, Alan in private splits up the patches really well,
so for me it tends to be even easier to apply Alans patches than Andreas,
but as with Alan, my one-liner "merged with xxxx" doesn't go into the detail
that Andrea and others actually do have). Now, the VM part of the patch was
certainly fairly big. I doubt much of it could have been reasonably split up,
though.
Andrea added, Yes, I considered
doing that but it would been quite a pain to develop it incrementally (so
I thought if needed I would have splitted it later).
In his same post, Benjamin also said, what
I'm deeply concerned with is the nature of patch merging. There was no
obvious public testing of the changes before merging, no warning of it, the
patch contained obvious bogus chunks and many unrelated changes. I've never
seen as invasive a patch merged that ran the risk of completely torpedoing
stability merged into a STABLE KERNEL SERIES, nor would I ever consider
submitting such a patch. There are bug fixes that are outstanding in -ac
that aren't being merged to -linus, yet this completely untested pile of
messy code is merged without hesitation?
Linus said in his reply:
Without hesitation? Hardly.
The bug fixes in -ac that aren't merged into -linus are that way BECAUSE NOBODY HAS SENT ME MERGES.
Alan works on it quite intensively, but the fact is, that for the -ac merge, Alan seems to be able to merge it slower than -ac grows. Which is why I actually started asking people to merge their parts from -ac into -linus to help Alan. That's how the other merge in -pre11 happened.
The aa tree has existed for a long time, and is actually mainted in better chunks than the -ac tree, which makes it easier to merge. Admittedly my and Alans tastes are often closer than mine and Andreas, which means that the -aa tree merges are more painful for _me_ ;)
Alan replied that in some cases he'd gotten bored of sending patches
over and over, and so didn't send them anymore, and added that in general,
I've been trying to ensure I feed stuff in testable
chunks. For example I dont want vfs and scsi changes both in a Linus merge
because someone is bound to go "hey I got corruption" and then with both in
one merge we are screwed.
Elsewhere, Alexei Podtelezhnikov remarked, I praise Linus for this step. Since 9-10 months ago Rik's
scheme didn't det enough attention to get fixed. Out of the main tree it
has better chances, just like it did before inclusion.
Rik van
Riel replied, Umm, we _have_ been fixing the VM
in 2.4, but Linus has been randomly ignoring patches and introducing stuff
we warned him not to apply which broke stuff. With maintainance like that,
I'm sure Andrea's code will also have a better chance out of the main tree
;)
Elsewhere, Alexander Viro said, Umm... Linus,
had you actually read through the fs/block_device.c part of that? It's not
just ugly as hell, it's (AFAICS) not hard to oops if you have several inodes
sharing major:minor. ->bd_inode and its treatment are bogus. Please,
read it through and consider reverting - in its current state code is an
ugly mess.
Linus replied:
Funny that you mention it, because I actually have a cunning plan, and you're an unwitting part of it.
Or actually, I hope you're a "witting" part of it, because it's going to be your code.
Take your "struct block_device" code, add a "struct address_space" to it, and whenever a block device inode is opened, make the inode->i_mapping point to &bdev->b_data, and voila..
You already get all the reference counting right, and it's the only sensible place to do it anyway, wouldn't you agree?
I thought you'd be thrilled. It seems to match your lazy allocation patch very well..
Alexander cursed violently, and replied:
Yes, we can make it work that way (see downthread). Yes, combined with lazy allocation (and pipefs-like scheme) it can turn into nice, _working_ code.
But right now we have
- broken patch applied to the tree
- somewhat tested patch that may (after being modified so that it would _apply_ to -pre11) fix the breakage. Once it's tested enough to be consider as a candidate for inclusion, that is.
IMNSHO it's somewhat less than ideal situation. I've already talked to with Andrea and once he gets back to life (no, 'e's just sleepin') we'll try to do something usable. Life would be much simpler if aforementioned cunning plan included sending mail to participants (me and Andrea) before putting the patch into the tree, though. Oh, well...
He added, It can be modified so that combination
with lazy-bdev and pipefs-like tree would work. And yes, most of the ugliness
would just go away.
To this, Linus replied:
That's the part I like about the page-cache bdev patch. It has a lot of fairly ugly warts, but all of them seem to be really fixable with _other_ cleanups, at which point only the good parts remain.
I agree that the timing may leave something to be desired. But we had the discussion about fixing pagecache-bdev consistency wrt the regular buffer cache filesystem accesses a week or so ago, and the fact is that nobody really seems to have started working on it - because everybody felt that you have to get everything done at once.
I don't have that feeling. I'm happy with having partial merge with ugly warts, if it means that you can get to the final stage _without_ having to have all the problems fixed at one time.
So now we have two _smaller_ merges that will fix two other issues, and remove all the horridness from the original merge.
Some implementation discussion followed. Elsewhere, Andreas Dilger said:
The real question is why can't we just open 2.5 and only fix the VM to start with? Leave the kernel at 2.4.10-pre10, and possibly use the -ac VM code (which has diverged from mainline), and leave people (Alan, Ben, Marcello, et. al.) who want to tinker with it in small increments and do the drastic stuff in 2.5.
Make it clear that 2.5 is still ONLY for VM and other bug fixes at this point, and not all of the long-awaited 2.5 rework YET. If it turns out that the VM fixes are done quickly, then they can be back-ported to 2.4. If it takes longer than expected you can open 2.5 up to general development.
With the right "management" it will be not much different than the current situation, except that people won't have fits about such huge changes going into 2.4. I think this is your subconcious telling you that you really wanted to start 2.5 a month ago.
There was some discussion in reply to this, in the course of which Rik said:
Look, the problem is that Linus is being an asshole and integrating conflicting ideas into both the VM and the VFS, without giving anybody prior notice and later blame others.
Just look at how he's now trying to force Al Viro into implementing his ideas yesterday because he broke stuff again...
If you want a stable kernel, use Alan's kernel.
Alexander replied:
Rik, in case you've missed that, I can and do speak for myself. I had spent ten years dodging the draft; when I decide to get enlisted into something it will happen on _my_ decision and _my_ conditions. When I decide that I'm being forced into something I do not accept - you'll know it from posting with URL of forked tree.
FWIW, I'm less than thrilled by the Andrea's patch, but it is salvagable. I'm also less than thrilled by the whole situation with VM - all sides of it. I seriously suspect that we need a limited multi-way fork in that area, so that you guys would stop stepping on each others' toes. I'm taking no part in your merry 5-way clusterfuck - sort that mess out between yourselves.
Again, when I decide that situation is unacceptable for me - I'll simply fork the tree. I do _not_ appreciate being enlisted into anyone's holy wars, so unless you really want to go _way_ up in my personal shitlist (several positions below .ru DoD) - don't play politics in my vicinity.
There was no reply.
Someone asked when XFS would be merged into the main kernel tree, and
Alan Cox replied, I can only speak for -ac but right
now I have no plan to tackle the merge except as an "its in 2.5, its ok in
2.5 backport" task.
Austin Gonyou asked if 2.5 would require tons of
changes to be made before merging, since 2.5 was supposed to be "radically
different" from 2.4; and Alan replied, Not really. 2.5
will change over time for certain but if anything the 2.5 changes will make
it easier. One problem area with XFS is that it duplicates chunks of what
should be generic functionality - and 2.5 needs to provide the generic paths
it wants.
Steve Lord asked, which chunks? One
of the frustrations we have had is the lack of feedback from anyone who has
looked at XFS.
Alan said, Send me a current
snapshot diff and I'll promise you some feedback. I didnt realise this was
an issue.
There followed some discussion of the various technical
issues surrounding XFS.
David Chow announced:
I am rewriting he wrapfs from the fist project and is now in a debugging stage, it is now quite ready for experimental tests.
The idea is orinigally from FiST, a stackable file system. But the FiST owner Erez seems given up to maintain the project. At the time I receive the code, it is so buggy, even unusable, lots of segmentation fault problems. I have debugging the fs for quite a while. Now it is useful in just use as a file system wrapper. It is useful in chroot environments and hardlinks aren't available. It wraps a directory and mount to another directory on tops of any filesystems. I wish to maintain this file system development since FiST's idea is good. It allow to use this base wrapfs as a template and then you can do encryption and other operations on it with fast development time. If any kernel file system maintainer is interested, please contact me .. I would like to get help to finish up my debugging work. The result will be GPL'ed. I will also package it with the fistgen package as a file system development tool.
Oystein Viggen asked if this wasn't identical to 'mount --bind' in 2.4,
and Alexander Viro replied, Bindings can be used
to get the same result, but underlying mechanics is different. Wrapfs is not
the most interesting application of FiST, so it's hardly a surprise...
David said, I think you people didn't understand what
is wrapfs, if is only a template for FiST. The aim is to provide a properly
maintained stackable template under linux, and so that people can use FiST
to develop their own filesystem. Currently the wrapfs template is so buggy,
I spend weeks to fix all the bugs and even rewriting some of the code to make
it more efficient. This dosn't means --bind, it means it also fix up tons
of FS'es that is previously produced by using the old buggy FiST template,
FiST is good for developing new stackable file system, the current problem
is that the templates are buggy....
And someone else gave links to http://www.isi.edu/~johnh/WORK/ucla.html
and http://www.isi.edu/~johnh/PAPERS/index.html.
End of thread.
Norbert Sendetzky announced:
I'm currently doing some research on implementiation of a new file system for my diplomathesis. It's about designing and implementing a network file system with security in mind. For those interested, there is a short introduction about why and how on my website (look at the Secure Internet File System section):
Dan Mann suggested also writing a Windows and MacIntosh client for this as well.
Keith Owens announced:
I have started work on the patch for /proc/sys/kernel/tainted with the corresponding modutils and ksymoops changes. insmod of a non-GPL module ORs /proc/sys/kernel/tainted with 1, insmod -f ORs with 2.
What to do about modules with no license? Complain and taint or silently ignore? A lot of modules in -ac14 have no MODULE_LICENSE, probably because they have no MODULE_AUTHOR. IMHO the default should be complain and taint, even though it will generate lots of newbie questions to l-k.
Timur Tabi asked what this was all about, and Keith gave a link to an earlier discussion.
Andrew Morton announced:
An ext3 patch against linux 2.4.10 is at
http://www.uow.edu.au/~andrewm/linux/ext3/
This patch is *lightly tested* - ie, it boots and does stuff. The changes to ext3 are small, but the kernel which it patches has recently changed a lot. If you're cautious, please wait a couple of days.
The patch retains the buffer-tracing code. This will soon be broken out into a separate patch to make ext3 suitable for submission for the mainstream kernel.
Changelog:
- Fix an oops which could occur at unmount time due to non-empty orphan list. This could be triggered by an earlier error during a truncate.
- Merge Ted's directory scan speedup heuristic.
- Remove the abort_write() address_space_operation by ensuring that all prepare_write() callers always call commit_write().
- A number of changes to suit the new 2.4.10 VM and buffer-layer design.
Michel A. S. Pereira asked where he could find some docs on
kernel hacking, and Andrew Ebling replied, I'm putting together a guide and kernel-hacking-HOWTO at: http://www.kernelhacking.org
Paul G. Allen said:
If this passes, everyone working in computer security can be arrested and thrown in prison for life. In addition, people such as Kevin Mitnick can be thrown back in prison even though they have already paid for their crime (double jeopardy?).
Alan Cox replied, Cuba is within small boat
distance. I thought it was going to be twenty years before the direction
changed, now Im not so sure.
Michael Rothwell remarked, I wonder if I could be put in jail next week because
of all that stupid cuecat stuff I was involved in?
And Dan Hollis
said:
The "WEP crack" fallout will be interesting to watch also.
In theory under the new law anyone whos computer was infected by nimda/codered could be imprisoned for life -- the new law says nothing about intent. So basically we would have a few million microsoft windows users serving life sentences...
Pavel Machek replied, It would be fun to try
to enforce that. Few million windows users in jail -- that sounds like bad
enough to kill stupid law.
Elsewhere, Jeff V. Merkey said:
When people are crashing planes into buildings and killing people by the thousands, hacking laws should be tough. The US has shut off internet access from Cyprus and several other places, and I've noticed a fall-off of hacking on my servers -- GOOD!.
Maureen O'Gara at Client Server News is based in NY, and from what she describes, the entire city is in a terrible state. Let anyone in New York know who is our friend on this list that the Utah Native American Church has sent James Mooney to New York City to conduct ceremonies for the victims and their families. The mayor's office has given us permission to conduct our ceremonies there for these people without fear of police harassment.
I am sending him enough peyote to trip out half the city. Anyone in NY who needs to find healing who is a member of our linux "Family" is welcome at these ceremonies. These people involved in this terrifying ordeal need to sit in a tepee and go somewhere else for a couple of days with the sacred medicine.
New York folks who wish to be involved in these ceremonies can call 212-755-0968 or 212-929-9396 to find out where and when. We have so far hosted thousands of the victims in these ceremonies. All are welcome and their families. The laws in New York allow non-Indians to use peyote for religious purposes of any race, unlike Utah. Tell our brothers we open our doors to those in need of spiritual and emotional healing for the people of New York.
These ceremonies are **FREE**. The Utah NAC is picking up the tab.
Several people replied to Jeff's first sentence. Pavel said, What do hacking laws have in common with planes crashing?
It was not hackers who crashed the planes, right?
And Rik van Riel
said, I guess people who believe terrorists will be
deterred by software licenses and laws about computer programs probably have
the politicians they deserve.
And Crutcher Dunnavant said to Jeff:
In what way has the recent violent acts differed significantly from acts which have been ongoing world-wide for, well, always? Is it that "it doesn't happen here!"? This is an increadibly US centric world view.
When the world seems to be at peace, it is easy to ask for your rights. It is when the war comes to you that you really need them, and that they are hardest to request.
This was a violent crime, commited by men who were willing to die. It was a failure of physical security; and massive databases will not make it harder for someone who is willing to sacrifice themselves.
But they will affect the ability of the population to conduct acts of civil disobediance and rebellion, upon which this and many other contries are founded.
The war in the world is not new, we are simply used to ignoring it. And for this, we are widely hated and scorned.
I will not grant the statement that "This sort of thing must be prevented at all costs". There are some prices I will not pay, and some that I will immediately distrust anyone who asks me to pay them.
I know that I am not making friends with this post, but my conscience demands that I respond to your blind aquescense of rights. I want a world in which my children can choose their life, even if the cost is a reduction in 'security'.
Eventually, David S. Miller said:
E-fucking-nough people. Stop this thread now, it is off topic.
There are many places out there where constructive conversations on this topic can be had, but vger is not one of them.
Please don't make Matti and I add more keyword filters to vger's list system to prevent this.
End of thread.
Chris Mason posted a bug report against 2.4.10-pre15 (involving the new VM
merges), and Alexander Viro said, It's solvable,
but not obvious. It _does_ solve coherency problems between device page
cache and buffer cache (thus killing update_buffers() and its ilk), but the
last issue (new access path to page-private buffer_heads) may be rather
nasty.
Linus Torvalds replied, It's
certainly solvable, but it is also certainly very fraught with tons of small
details.
Pavel Machek replied, Time to
rename 2.4.10 to 2.5.0? ;-)
.