On Tue, Mar 19, 2013 at 9:04 PM, David Lang wrote:
> On Wed, 20 Mar 2013, Martin Steigerwald wrote:
>
>> Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
>>>
>>> On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote:
>>>>
>>>> On M
On Tue, Mar 19, 2013 at 11:54 PM, Rob Landley wrote:
> I'm confused, http://tux3.org/ lists a bunch of dates from 5 years ago, then
> nothing. Is this project dead or not?
Not. We haven't done much about updating tux3.org lately, however you
will find plenty of activity here:
https://github
On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote:
> On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote:
>> On Mon, Jan 28, 2013 at 03:27:38PM -0800, David Lang wrote:
>> > The situation I'm thinking of is when dealing with VMs, you make a
>> > filesystem image once and clone it mu
On Sun, Jan 27, 2013 at 10:02 PM, David Lang wrote:
> On Sun, 27 Jan 2013, Daniel Phillips wrote:
> The thing that jumps out at me with this is the question of how you will
> avoid the 'filesystem image in a file' disaster that reiserfs had (where
> it's fsck could mix
On Friday 25 January 2008 05:33, Theodore Tso wrote:
> and then detect the
> deadlock case where the process holding the file descriptor used to
> freeze the filesystem gets frozen because it attempted to write to the
> filesystem --- at which point it gets some kind of signal (which
> defaults to
On Sunday 10 February 2008 23:53, Greg KH wrote:
> I don't think there's much more we need to do here, do you?
No amount of information about such a thing is too much information. We
do not need to do any more, but we can do more.
It is news, how about an entry in the kernel.org news section?
Kudos to all involved in the rapid response. But.
Information on patching this vulnerability is not available front and
center in many of the places you would expect: kernel.org front page,
debian.org front page, covered on planet.debian.org but without a
pointer to the patch, and so on. So t
On Sunday 10 February 2008 23:49, Pekka Enberg wrote:
> Hi Daniel,
>
> On Feb 11, 2008 9:29 AM, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > I think many users would first go to kernel.org on a day like
> > today, as I did. Nothing to see there. We could do a way be
Hi everybody,
The Tux3 project has some interesting news to report for the new year. In
brief, the first time Hirofumi ever put together all the kernel pieces in his
magical lab over in Tokyo, our Tux3 rocket took off and made it straight to
orbit. Or in less metaphorical terms, our first meani
On Tuesday, January 01, 2013 02:06:19 PM Martin Steigerwald wrote:
> Sounds all good and nice and interesting to test, but where to grab the
> source?
>
> I found no obvious URL.
Hi Martin,
Sorry about that, I knew I forgot something:
git://github.com/OGAWAHirofumi/tux3.git
Warning: the re
Hi Martin,
Thanks for the "tux3 howto". Obviously tux3.org needs refresh, but you hit the
main points.
On Tuesday, January 01, 2013 03:37:08 PM you wrote:
> Writing a file with
>
> ./tux3 write tux3.img /etc/fstab
>
> also seemed to work, but I gave up holding down the enter key at:
>
> delta
On Tuesday, January 01, 2013 10:58:35 PM Shentino wrote:
> From what I can tell on the design, tux3 is "fsync satiating" with a
> single disk write. It writes the data to the final location, updates
> the log, and at that point the data is considered committed and it can
> let userspace go on its
On Wednesday, January 02, 2013 11:45:29 AM Tero Roponen wrote:
> I have not looked at Tux3 for a long time, but there seems to be
> a simple fix for at least this problem, and two workarounds...
Wow, that was fast. Martin, does this work for you?
Regards,
Daniel
--
To unsubscribe from this list:
Greetings all,
From time to time, one may fortunate enough to be blessed with a
discovery in computer science that succeeds at improving all four of
performance, scalability, reliability and simplicity. Of these normally
conflicting goals, simplicity is usually the most elusive. It is
therefo
Hi Christian,
You are welcome, and I hope that your project can make good use of this
technology. Please do credit your sources if you use these ideas, and
please keep the CC list intact in further replies.
What is the scale of your application, that is, how many index entries
do you expect?
On 06/20/2013 12:12 PM, Christian Stroetmann wrote:
> 1. Stop copying my intellectual properties related with file systems and
> implementing them. You always came several months too late and I am not
> interested to let it become a running gag, definitely.
> 2. Stop marketing my ideas, especially
One month ago we reported that Tux3 is now able to beat tmpfs in at
least one benchmark load, a claim that generated considerable lively
commentary, some of it collegial:
https://lkml.org/lkml/2013/5/7/742
Ted raised an interesting question about whether Tux3 is forever
destined to suffer
Hi Dave,
On Wed, Jun 26, 2013 at 9:47 PM, Dave Chinner wrote:
> You have your own wait code, that doesn't make what the VFS does
> unnecesary. Quite frankly, I don't trust individual filesystems to
> get it right - there's a long history of filesystem specific data
> sync problems (including in X
On Wed, Jun 26, 2013 at 10:18 PM, OGAWA Hirofumi
wrote:
> ...vfs can't know the data is whether after sync point or before
> sync point, and have to wait or not. FS is using the behavior like
> data=journal has tracking of those already, and can reuse it.
Clearly showing why the current interface
Hi Ted,
On Thu, Jun 27, 2013 at 11:36 AM, Theodore Ts'o wrote:
> If the goal is to optimize file system freeze operations, sure. But
> that's also not a common operation, so if it burns a little extra CPU
> time, it wouldn't cause me to think that it was a high priority issue.
> Decreasing the w
n
indexing scheme with the properties I was seeking. This is what
Hirofumi and I have busy prototyping and testing for the last few
weeks. More below...
On Thu, Mar 21, 2013 at 6:57 PM, Dave Chinner wrote:
> On Wed, Mar 20, 2013 at 06:49:49PM -0700, Daniel Phillips wrote:
>> At the moment we&#x
On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".
Brilliant, and +1 for a session at KS. In the mean time, why don't we
all try to demonstrate the real meaning of respect and civility, by
prac
On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> I think you need more than "hope" to change one of the fundamental
> rules of LKML; be open and honest, even if that means expressing your
> opinion in a way that others might consider offensive and colorful.
Logical fallacy type: bifurcation. You
On 07/22/2013 09:02 PM, Luck, Tony wrote:
> Some thoughts on the format of the discussion at KS:
>
> ...
>
5) Volunteers are under-represented at Kernel Summit
Volunteers are the "dark matter" of Linux Kernel contribution. They are
not the "usual suspects" who nearly all have full time jobs now,
On 07/24/2013 12:51 AM, Felipe Contreras wrote:
> Your mistaken fallacy seems to be that you think one can *always* be
> both A (open and honest), and B (polite)...
You are are right, I do think that you can *always* be both open and
honest, and polite. I do not believe that I am mistaken. And I
On 07/25/2013 02:34 PM, Willy Tarreau wrote:
> Guys, could we please stop this endless boring thread ?
Willy, I believe we are on the same side of the civility debate, but I
somehow got the feeling that you just characterized my comment re "open
and honest" as "endless and boring".
I agree that
Hi Willy,
I understand completely. I don't blame you. Filter the thread. Done.
I am not tired of the subject, quite the contrary. Please do not speak
for me in that regard. After many years of wandering in the toxic
wasteland, finally some actual progress.
Regards,
Daniel
--
To unsubscribe fr
Hi Dave,
Thanks for the catch - I should indeed have noted that "modified
dbench" was used for this benchmark, thus amplifying Tux3's advantage
in delete performance. This literary oversight does not make the
results any less interesting: we beat Tmpfs on that particular load.
Beating tmpfs at any
(resent as plain text)
On Sat, May 11, 2013 at 2:26 PM, Theodore Ts'o wrote:
> Dropping fsync() does a lot more than "amplify Tux3's advantage in
> delete performace". Since fsync(2) is defined as not returning until
> the data written to the file descriptor is flushed out to stable
> storage --
On Sat, May 11, 2013 at 11:35 AM, james northrup
wrote:
> also interesting information... Study of 2,047 papers on PubMed finds
> that two-thirds of retracted papers were down to scientific
> misconduct, not error
Could you please be specific about the meaning you intend? Because
innuendo is less
Hi Ted,
You said:
> ...any advantage of decoupling the front/back end
> is nullified, since fsync(2) requires a temporal coupling
After after pondering it for a while, I realized that is not
completely accurate. The reduced delete latency will
allow the dbench process to proceed to the fsync poi
Interesting, Andreas. We don't do anything as heavyweight as
allocating an inode in this path, just mark the inode dirty (which
puts it on a list) and set a bit in the inode flags.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
When something sounds to good to be true, it usually is. But not always. Today
Hirofumi posted some nigh on unbelievable dbench results that show Tux3
beating tmpfs. To put this in perspective, we normally regard tmpfs as
unbeatable because it is just a thin shim between the standard VFS mechanisms
Hi David,
On Wednesday 20 February 2008 08:05, David Howells wrote:
> These patches add local caching for network filesystems such as NFS.
Have you got before/after benchmark results?
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Thursday 21 February 2008 16:07, David Howells wrote:
> The way the client works is like this:
Thanks for the excellent ascii art, that cleared up the confusion right
away.
> What are you trying to do exactly? Are you actually playing with it, or just
> looking at the numbers I've produced?
On Monday 04 February 2008 19:27, Linus Torvalds wrote:
> On Tue, 5 Feb 2008, Maxim Levitsky wrote:
> > The x86 tree was merged several times, but I don't see kgdb
> > included in latest mainline -git.
> >
> > So just one question, will it be included or no?
>
> I won't even consider pulling it unl
On Wednesday 06 February 2008 04:08, Jan Kiszka wrote:
> While too many people consider a debugger as _the_ tool for kernel
> development, which it clearly isn't, it remains a fairly useful
> feature, and I don't see any regression, technically or
> organizationally, it may introduce to Linux. IMHO
On Friday 22 February 2008 04:48, David Howells wrote:
> > But looking up the object in the cache should be nearly free - much less
> > than a microsecond per block.
>
> The problem is that you have to do a database lookup of some sort, possibly
> involving several synchronous disk operations.
Ri
On Monday 25 February 2008 15:19, David Howells wrote:
> So I guess there's a problem in cachefiles's efficiency - possibly due
> to the fact that it tries to be fully asynchronous.
OK, not just my imagination, and it makes me feel better about the patch
set because efficiency bugs are fixable wh
I need to respond to this in pieces... first the bit that is bugging
me:
> > * two new page flags
>
> I need to keep track of two bits of per-cached-page information:
>
> (1) This page is known by the cache, and that the cache must be informed if
> the page is going to go away.
I still
On Tuesday 26 February 2008 06:33, David Howells wrote:
> > Suppose one were to take a mundane approach to the persistent cache
> > problem instead of layering filesystems. What you would do then is
> > change NFS's ->write_page and variants to fiddle the persistent
> > cache
>
> It is a requirem
For the past several weeks I have been developing a directory index
facility for Ext2, with good results so far. This note describes the
on-disk format of the new index.
The development work has reached the point where the format is nearly
ready to be frozen, so I hope that the material I have p
> Are you going to go to a COMPAT flag before final release? This is
> pretty much needed for e2fsck to be able to detect/correct indexes.
I will if I know what the exact semantics are. I have only an
approximate idea of how this works and I'd appreciate a more precise
definition.
> One thing
cat calahan.reply.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/
On Tuesday 10 April 2001 18:37, you wrote:
> Daniel Phillips writes:
> > The zeroth block of an indexed directory is the index root. Initially
> > the index has only one block. The following blocks are normal ext2
> > directory entry blocks. When the directory grows
Jamie Lokier wrote:
> Daniel Phillips wrote:
> > ls already can't handle the directories I'm working with on a regular
> > basis. It's broken and needs to be fixed. A merge sort using log n
> > temporary files is not hard to write.
>
> ls -U | sort
&g
Andreas Dilger wrote:
> Daniel writes:
> > > Are you going to go to a COMPAT flag before final release? This is
> > > pretty much needed for e2fsck to be able to detect/correct indexes.
> >
> > I will if I know what the exact semantics are. I have only an
> > approximate idea of how this works a
>Daniel Phillips wrote:
> > Jamie Lokier wrote:
> > > Daniel Phillips wrote:
> > > > ls already can't handle the directories I'm working with on a regular
> > > > basis. It's broken and needs to be fixed. A merge sort using log n
> &
Andreas, you wrote:
> Daniel, you write:
> > So then, the obvious candidate would be:
> >
> > #define EXT2_FEATURE_RO_COMPAT_DIR_INDEX0x0004
> >
> > which was formerly EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
>
> Actually not. We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> becaus
Andreas, you wrote:
> Daniel, you write:
> > Andreas, you wrote:
> > > We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> > > because the on-disk layout is 100% compatible with older kernels, so
> > > no reason to force read-only for those systems. I'm guessing Ted had
> > > put RO_COMPAT
On Monday 16 April 2001 14:40, you wrote:
> Daniel, you write (re indexed directories):
> > Superblock Feature Flag
> > ---
> >
> > This is now incorporated. I use the following code:
> >
> > if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
> > {
> >
A few weeks ago, testing my indexed directory code with a 1,000,000 file
directory, I noticed that deletion was taking longer than creation -
about 4 times longer. Andreas Dilger confirmed this earlier this week,
and I decided I'd better find out what's going on.
Not having any nice tracing tool
Al Viro wrote:
> Folks, IMO ext2-dir-patch got to the stable stage. Currently
> it's against 2.4.4-pre2, but it should apply to anything starting with
> 2.4.2 or so.
>
> Ted, could you review it for potential inclusion into 2.4 once
> it gets enough testing? It's ext2-only (the only change
Jan Harkes wrote:
> On Thu, Apr 19, 2001 at 02:27:48AM +0200, Daniel Phillips wrote:
> > more memory. If you have enough memory, the inode cache won't thrash,
> > and even when it does, it does so gracefully - performance falls off
> > nice and slowly. For example, 2
Rik van Riel wrote:
> On Thu, 19 Apr 2001, Daniel Phillips wrote:
> > Jan Harkes wrote:
> > > On Thu, Apr 19, 2001 at 02:27:48AM +0200, Daniel Phillips wrote:
> > > > more memory. If you have enough memory, the inode cache won't thrash,
> > > &g
Rik van Riel wrote:
> On Thu, 19 Apr 2001, Daniel Phillips wrote:
>
> > OK, now I know what's happening, the next question is, what should be
> > dones about it. If anything.
>
> [ discovered by alexey on #kernelnewbies ]
>
> One thing we should do is m
> On Wed, 18 Apr 2001, Rik van Riel wrote:
> > One thing we should do is make sure the buffer cache code sets
> > the referenced bit on pages, so we don't recycle buffer cache
> > pages early.
> >
> > This should leave more space for the buffercache and lead to us
> > reclaiming the (now unused) s
On Fri, 20 Apr 2001, Andreas Dilger wrote:
> The included patch updates Documentation/filesystems/ext2 to reflect
> current information about ext2. It also adds some more information
> that people have told me is hard to find in other places (such as a
> description of the superblock compatibilit
Earlier this month a runaway installation script decided to mail all its
problems to root. After a couple of hours the script aborted, having
created 65535 entries in Postfix's maildrop directory. Removing those
files took an awfully long time. The problem is that Ext2 does each
directory acces
On Tue, 20 Feb 2001, Linus Torvalds wrote:
> In article <01022020011905.18944@gimli>,
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> >Earlier this month a runaway installation script decided to mail all its
> >problems to root. After a couple of hours the script ab
On Tue, 20 Feb 2001, Jeremy Jackson wrote:
> Mike Dresser wrote:
>
> > the way i'm reading this, the problem is there's 65535 files in the directory
> > /where/postfix/lives. rm * or what have you, is going to take forever and
> > ever, and bog the machine down while its doing it. My understand
On Wed, 21 Feb 2001, Bernd Eckenfels wrote:
> In article <01022100361408.18944@gimli> you wrote:
> > But actually, rm is not problem, it's open and create. To do a
> > create you have to make sure the file doesn't already exist, and
> > without an index you have to scan on average half the direct
"H. Peter Anvin" wrote:
>
> Martin Mares wrote:
> >
> > > True. Note too, though, that on a filesystem (which we are, after all,
> > > talking about), if you assume a large linear space you have to create a
> > > file, which means you need to multiply the cost of all random-access
> > > operatio
"H. Peter Anvin" wrote:
>
> Andreas Dilger wrote:
> >
> > Basically (IMHO) we will not really get any noticable benefit with 1 level
> > index blocks for a 1k filesystem - my estimates at least are that the break
> > even point is about 5k files. We _should_ be OK with 780k files in a single
> >
Linus Torvalds wrote:
>
> On Tue, 20 Feb 2001, Daniel Phillips wrote:
> >
> > You mean full_name_hash? I will un-static it and try it. I should have
> > some statistics tomorrow. I have a couple of simple metrics for
> > measuring the effectiveness of the ha
Andreas Dilger wrote:
>
> Daniel Phillips writes:
> > Easy, with average dirent reclen of 16 bytes each directory leaf block
> > can holds up to 256 entries. Each index block indexes 512 directory
> > blocks and the root indexes 511 index blocks. Assuming the leaves are
"H. Peter Anvin" wrote:
>
> Daniel Phillips wrote:
> >
> > Have you looked at the structure and algorithms I'm using? I would not
> > call this a hash table, nor is it a btree. It's a 'hash-keyed
> > uniform-depth tree'. It n
On Thu, 22 Feb 2001, [EMAIL PROTECTED] wrote:
> A couple of comments. If you make the beginning of each index block
> look like a an empty directory block (i.e, the first 8 blocks look like
> this):
>
> 32 bits: ino == 0
> 16 bits: rec_len == blocksize
> 16 bits: name_len = 0
>
Linus Torvalds wrote:
>
> On Thu, 22 Feb 2001, Daniel Phillips wrote:
> >
> > In the first heat of hash races - creating 20,000 files in one directory
> > - dentry::hash lost out to my original hack::dx_hash, causing a high
> > percentage of leaf blocks to remain
Andreas Dilger wrote:
> Daniel writes:
> > All references to "." and ".." are now intercepted and never reach the
> > filesystem level.
>
> Ted writes:
> >From: Daniel Phillips <[EMAIL PROTECTED]>
> >
> >I'll leave t
[EMAIL PROTECTED] wrote:
>
> Just looking at R5 I knew it wasn't going to do well in this application
> because it's similar to a number of hash functions I tried with the same
> idea in mind: to place similar names together in the same leaf block.
> That turned out to be not very
ludovic fernandez wrote:
> The following patch makes the kernel preemptable.
> It is against 2.4.0-prerelease on for i386 only.
> It should work for UP and SMP even though I
> didn't validate it on SMP.
> Comments are welcome.
I was expecting to see this sometime in 2.5, not quite so soon...
The
Alex Belits wrote:
>
> On Wed, 3 Jan 2001, Daniel Phillips wrote:
>
> > I don't doubt that if the 'power switch' method of shutdown becomes
> > popular we will discover some applications that have windows where they
> > can be hurt by sudden shut
Helge Hafting wrote:
>
> [...]
> > > Being able to shut down by hitting the power switch is a little luxury
> > > for which I've been willing to invest more than a year of my life to
> > > attain. Clueless newbies don't know why it should be any other way, and
> > > it's essential for embedded d
Linus Torvalds wrote:
> I'd rather just change the rule that "writepage()" will clear the dirty
> bit itself and always unlock (and "1" just to inform the upper layers that
> the page cannot be thrown away).
Change to that rule or from? I *think* you just said:
- If ->writepage successfully s
"Stephen C. Tweedie" wrote:
>
> On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
> >
> > Tux2 is explicitly designed to legitimize pulling the plug as a valid
> > way of shutting down. Metadata-only journalling filesystems are not
> > des
ludovic fernandez wrote:
> Right now I will be interested to run some benchmarks (latency but
> also performance) to see how the system is disturbed by beeing
> preemptable. I'm little bit lost on this and I don't know where to start.
> Do you have any pointers on benchmark suites I could run ?
>
Mark Hahn wrote:
> > I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to
> ...
> > afraid that this may partialy criple 2.2 driver development.
>
> egads! how can there be "development" on a *stable* kernel line?
>
> maybe this is the time to reconsider terminology/polic
Nathan Scott wrote:
> On Jan 5, 3:26am, Daniel Phillips wrote:
> > ...
> > This filesystem mount option parsing code is completely ad hoc, and uses
> > strtok which is horribly horribly broken. (Do man strtok and read the
> > 'Bugs' section.)
> >
>
Laramie Leavitt wrote:
>
> I seem to be getting a rather odd kernel lockup on 2.4.
> I am using XFree 3.3.6 ( I believe ).
>
> Whenever I start X, my session starts up like normal,
> but soon locks HARD. Is this a known issue? I
> suspected the fb stuff, and so I removed it and the
> problem r
Marcelo Tosatti wrote:
>
> On Fri, 5 Jan 2001, Chris Mason wrote:
>
> >
> > Here's the latest version of the patch, against 2.4.0. The
> > biggest open issues are what to do with bdflush, since
> > page_launder could do everything bdflush does.
>
> I think we want to remove flush_dirty_buffers
On Fri, 05 Jan 2001, Rik van Riel wrote:
> Hi,
>
> here is a TODO list for the memory management area of the
> Linux kernel, with both trivial things that could be done
> for later 2.4 releases and more complex things that really
> have to be 2.5 things.
>
> Most of these can be found on http://
Jared Sulem wrote:
> Driver should work after applying the following patch. I'm not a kernel
> hacker so I don't know how good a solution this is (especially suspicious
> of the work around in os-interface.c) but X works on my machine and it has
> not crashed (yet) - have not tried any OpenGL tho
Hans-Joachim Baader wrote:
> I got an oops with 2.4.0-ac2. It said "Kernel Panic: Attempt to kill init"
> or similar. The oops didn't make it into the log but I photographed it
> and reconstructed it from the photos (USB digital cams are a great thing
> :-). After the oops, the machine was still r
david wrote:
>
> hi all
>
> i now need to read a file from in the kernel 2.2.x
> dose any one know how to this ?
Look at open_exec and kernel_read, but also consider whether you could
solve your problem more elegantly with help from user space. (This
should be in the FAQ.)
--
Daniel
-
To unsu
Alan Cox wrote:
>
> > +
> > + /* FAT cannot truncate to a longer file */
> > + if (attr->ia_valid & ATTR_SIZE) {
> > + if (attr->ia_size > inode->i_size)
> > + return -EPERM;
> > + }
> >
> > error = inode_change_ok(inode, attr);
> >
After 3 days up doing fairly normal things with an unremarkable
configuration and a vanila 2.4.0 kernel (nfs) I tried to log out of KDE
and hung in 'preparing session for logout'. In a text console, dmesg
showed an infinite number of "Free blocks count corrupted" messages:
EXT2-fs error (devi
Jeff Dike wrote:
>
> You've got two problems here, and one of them is mine:
>
> > In uml I continue the debian installation off of cdrom and as I say ok
> > to the final screen I get a "Kernel panic: Kernel mode fault at addr
> > 0xbefffe90, ip 0x1009f315" from user-mode linux which is running a
"Michael D. Crawford" wrote:
>
> Regarding notification when there's a change to the filesystem:
>
> This is one of the most significant things about the BeOS BFS filesystem, and
> something I'd dearly love to see Linux adopt. It makes an app very efficient,
> you just get notified when a direc
Jesse Pollard wrote:
> Daniel Phillips <[EMAIL PROTECTED]>:
> > This may be the most significant new feature in 2.4.0, as it allows us
> > to take a fundamentally different approach to many different problems.
> > Three that come to mind: mail (get your mail instantly
"Stephen C. Tweedie" wrote:
> On Tue, Jan 09, 2001 at 04:45:10PM +0100, Christoph Rohland wrote:
> >
> > AFAIU mlock'ed pages would never get deactivated since the ptes do not
> > get dropped.
>
> D'oh, right --- so can't you lock a segment just by bumping page_count
> on its pages?
Putting this
Linus Torvalds wrote:
> (This is why I worked so hard at getting the PageDirty semantics right in
> the last two months or so - and why I released 2.4.0 when I did. Getting
> PageDirty right was the big step to make all of the VM stuff possible in
> the first place. Even if it probably looked a bi
Mark Hindley wrote:
> I am running 2.4.0 final. I got the following failed paging request which
> produced a complete freeze.
>
> As you can see it was precipitated by cron starting to run some
> housekeeping stuff overnight.
>
> Has anyone else had prblems?
It looks real. It was executing thi
Jamie Lokier wrote:
>
> Daniel Phillips wrote:
> > It was done last year, quietly and without fanfare, by Stephen Rothwell:
> >
> > http://www.linuxcare.com/about-us/os-dev/rothwell.epl
> >
> > This may be the most significant new feature in 2.4.0, as it a
Jamie Lokier wrote:
> Daniel Phillips wrote:
> > [things that can benefit from dnotify]
> > locate (reindex only those directories that have changed, keep index
> > database current).
>
> Not a chance. dnotify doesn't work recursively, so you can't monit
Jamie Lokier wrote:
>
> Daniel Phillips wrote:
> > DN_OPEN A file in the directory was opened
> >
> > You open the top level directory and register for events. When somebody
> > opens a subdirectory of the top level directory, you receive
> >
Jesse Pollard wrote:
>
> Daniel Phillips <[EMAIL PROTECTED]>:
> > Jamie Lokier wrote:
> > >
> > > Daniel Phillips wrote:
> > > > DN_OPEN A file in the directory was opened
> > > >
> > > > You open the top
"David S. Miller" wrote:
> 2) It affects only code which can burn a lot of cpu without
> scheduling. Compare this to schemes which make the kernel
> fully pre-emptable, causing _EVERYONE_ to pay the price of
> low-latency
Is there necessarily a pr
Keith Owens wrote:
> I want to completely remove this multi layered method for setting
> initialisation order and go back to basics. I want the programmer to
> say "initialise E and F after G, H and I". The kernel build system
> works out the directed graph of initialisation order then controls
Peter Samuelson wrote:
>
> [Torsten Duwe]
> > > "Francis" == Francis Galiegue <[EMAIL PROTECTED]> writes:
> >
> > >> + if ((*p & 0xdf) >= 'a' && (*p & 0xdf) <= 'z') continue;
> >
> > Francis> Just in case... Some modules have uppercase letters too :)
> >
> > That's what the &0xdf is i
1 - 100 of 738 matches
Mail list logo
