On Thu, 14 Jun 2001, Alan Cox wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far
On Wed, 13 Jun 2001, Ralf Baechle wrote:
> On Wed, Jun 13, 2001 at 03:25:22AM -0700, Ion Badulescu wrote:
> > Date: Wed, 13 Jun 2001 03:25:22 -0700
> > From: Ion Badulescu <[EMAIL PROTECTED]>
> > To: Riley Williams <[EMAIL PROTECTED]>
> > Cc: Shawn Starr <[EMAIL PROTECTED]>, <[EMAIL PROTECT
On Tue, 12 Jun 2001, Pavel Machek wrote:
> Hi!
>
> > I just had one of the "3com Etherlink 10/100 PCI NIC with 3XP processor"
> > float accross my desk, I was wondering how much the linux kernel uses the
> > 3xp processor for its encryption offloading and such. According to the
> > hype it does
On 9 Jun 2001, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:"Albert D. Cahalan" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > >
> > > But in spite of all this, you're not really measure the critical
> > > temperature, which is junction tempature. Yes, case
On Sat, 26 May 2001, Jeff Garzik wrote:
> Cesar Da Silva wrote:
> > The features that I'm wondering about are:
> > * Dynamic Processor Resilience
>
> is this fault tolerance? I think if a CPU croaks, you are dead.
>
> There are patches for hot swap cpu support, but I haven't seen any CPU
> fault
On Fri, 25 May 2001, Adam J. Richter wrote:
> Larry McVoy wrote:
> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
> >It's also about the concept of boundaries - if you think that that
> >concept is not a legal one then why aren't all programs which are run
> >on top of a GPLed
On Sat, 17 Feb 2001, Patrick Michael Kane wrote:
> * Pavel Machek ([EMAIL PROTECTED]) [010217 05:40]:
> > Being able to remotely resed machine with crashed userland would be
> > *very* nice, too...
>
> If it provides a true remote console, enable SYSRQ and youi should get this
> for free.
Yes,
On Fri, 16 Feb 2001, Michael H. Warfield wrote:
> On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote:
> > On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> > > I did some research on the patent database and found nothing regarding such
> > > a patent. There's patent on word processors (
On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> I did some research on the patent database and found nothing regarding such
> a patent. There's patent on word processors (not the concept but related to)
> and uses tab on the description...and that patent is from 1980.
Perhaps that's it, then
On Fri, 16 Feb 2001, David D.W. Downey wrote:
> Would someone tell me where you get all this lovely information on
> patents held by M$? I can't find anything.
Sorry, it's *IBM* who are said to hold a patent on the tab key.
Legend has it Microsoft once found a patent of theirs which IBM appeare
On Fri, 16 Feb 2001, Rik van Riel wrote:
> On Thu, 15 Feb 2001, Alan Olsen wrote:
>
> > I expect the next thing that will happen is that they will get
> > patents on key portions of their protocols and then start
> > enforcing them.
>
> If Microsoft would start pissing off IBM and other major
>
On Fri, 16 Feb 2001, Rogier Wolff wrote:
> Jeff Garzik wrote:
> > On Fri, 16 Feb 2001, Rogier Wolff wrote:
> > > I have a bunch of computers with 8139 cards. When I moved the cables
> > > over from my hub to my new switch all the "full duplex" lights came on
> > > immediately.
> > >
> > > Would t
On Fri, 16 Feb 2001, Rogier Wolff wrote:
> James Sutherland wrote:
> > > That would explain me seeing way too many collisions on that old hub
> > > (which obviously doesn't support full-duplex).
> >
> > No, it would just prevent your card working. Larg
On Fri, 16 Feb 2001, Helge Hafting wrote:
> They are wrong about linux stifling innovation, there is plenty of
> innovation in linux itself.
Indeed. If Linux did nothing new, what do they have to fear?!
> On the other hand:
> ''I can't imagine something that could be worse than this
> for the
On Fri, 16 Feb 2001, Rogier Wolff wrote:
>
> Hi All,
>
> I have a bunch of computers with 8139 cards. When I moved the cables
> over from my hub to my new switch all the "full duplex" lights came on
> immediately.
That's what you would expect: they will auto-negotiate full duplex, in the
same
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Tue, 13 Feb 2001, Tim Waugh wrote:
> > Here's a patch that fixes a bug that can cause PCI driver list
> > corruption. If parport_pc's init_module fails after it calls
> > pci_register_driver, cleanup_module isn't called and so it's still
> > registere
On Tue, 13 Feb 2001, Jeremy Jackson wrote:
(Long description of how to create a non-executable stack on x86)
I'm afraid you just reinvented the wheel. The idea has been around for a
long time, and it was OK as a quick hack to stop existing exploits
working, but it's possible to modify a buffer o
On Tue, 13 Feb 2001, Russell King wrote:
> James Sutherland writes:
> > If the kernel starts spewing data faster than you can send it to the far
> > end, either the data gets dropped, or you block the kernel. Having the
> > kernel hang waiting to send a printk to the far
On Tue, 13 Feb 2001, Alan Cox wrote:
> > That's the whole crux of the matter. For something like this, you *will*
> > drop data under certain circumstances. I suspect it's better to have
> > this done in a controlled manner, rather than stop completely, which is
> > what TCP would do.
>
> Why
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> James Sutherland wrote:
> > >
> > > Depends on what the client can handle. For the kernel, that might be
> > > true, but for example a boot loader may only have a few K worth of buffer
> > > space.
> >
&g
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> Alan Cox wrote:
> >
> > > > Explain 'controlled buffer overrun'.
> > >
> > > That's probably the ability to send new data even if there's unacked old
> > > data (e.g. because the receiver can't keep up or because we've had losses).
> >
> > Well let m
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> James Sutherland wrote:
> >
> My thinking at the moment is to require kernel IP configuration (either
> ip= or RARP/BOOTP/DHCP). It seems to be the only practical way;
> otherwise you miss too much at the beginning. However,
On Mon, 12 Feb 2001, Alan Cox wrote:
> > > I have toyed a few times about having a simple Ethernet- or UDP-based
> > > console protocol (TCP is too heavyweight, sorry) where a machine would
> > > seek out a console server on the network. Anyone has any ideas about
> > > it?
> >
> > Excellent pl
On 12 Feb 2001, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Ivan Passos <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Since I still want to add support for speeds up to 115200, the other two
> > questions are still up (see below):
> >
> > > - If not,
On Sun, 11 Feb 2001, Pavel Machek wrote:
> Hi!
>
> > duh. I sent this to rutgers originally..
>
> I'm doing same mistake over and over.
>
> Perhaps creating forward at vger.rutgers.edu would be good thing (tm)?
Apparently the rutgers.edu people didn't like this idea...
If they'd been feelin
On Mon, 12 Feb 2001, Alan Cox wrote:
> > > queued_writes=1;
> > > return;
> >
> > Just what happens when you run out of dmesg ring in an interrupt ?
>
> You lose a couple of lines. Big deal. I'd rather lose two lines a year on
> a problem (and the dmesg ring
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 th
On Tue, 6 Feb 2001, Ray Strode wrote:
> >We'd like to run an editorial this coming Saturday about the
> >journaling filesystems available for Linux. We'd like an author who
> >isn't a developer on any of them so he/she can give an object analysis
> >of the pros and cons of each and share thought
On Mon, 5 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > In an __init function, have some code that will trigger the bug.
> > > This can be used to disable Reiserfs if the compiler was bad.
> > > Then the admin gets a printk() and the Reiserfs mount fails.
> >
> > Thats actually quite
On Mon, 5 Feb 2001, Steve Underwood wrote:
> James Sutherland wrote:
> > On Sun, 4 Feb 2001, Ben Ford wrote:
> > > David Woodhouse wrote:
> > > > On Sun, 4 Feb 2001, James Sutherland wrote:
> > > >
> > > > > For the end-user, the ability
On Sun, 4 Feb 2001, Ben Ford wrote:
> David Woodhouse wrote:
>
> > On Sun, 4 Feb 2001, James Sutherland wrote:
> >
> > > For the end-user, the ability to see readings in other units would be
> > > useful - how many people on this list work in litres/metr
On Sat, 3 Feb 2001, Russell King wrote:
> Albert D. Cahalan writes:
> > The units seem to vary. I suggest using fundamental SI units.
> > That would be meters, kilograms, seconds, and maybe a very
> > few others -- my memory fails me on this.
>
> iirc, SI comes from France, and therefore it shou
On Fri, 2 Feb 2001, David Lang wrote:
> Thanks, that info on sendfile makes sense for the fileserver situation.
> for webservers we will have to see (many/most CGI's look at stuff from the
> client so I still have doubts as to how much use cacheing will be)
CGI performance isn't directly affecte
On Sat, 3 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > It makes sense to refuse to build a piece of the kernel if it break's
> > > a machine - anything else is a timebomb waiting to explode.
> >
> > The logical conclusion of that is to replace the entire kernel tree with
> >
> > #er
On Wed, 31 Jan 2001, Bernd Eckenfels wrote:
> On Wed, Jan 31, 2001 at 09:24:39AM +0000, James Sutherland wrote:
> > 32 megaBLOCK?? How big is it in Mbytes?
>
> Blocksize is 4k, mkreiserfs in my version is telling me it can not generate
> partitions smaller than 32M but it is n
On Wed, 31 Jan 2001, Grzegorz Sojka wrote:
> I am using kernel v2.4.0 on Abit BP6 with two Intel Pentium Celeron
> 366@517Mhz + video based on Riva TNT2 M64 32Mb + network card 3com 3c905b
> + Creative Sound Blaster 64 pnp isa and hercules video card. I'm geting
> all over the time messages like
On Wed, 31 Jan 2001, Alan Cox wrote:
> > > In the intel databook. Generally an MCE indicates hardware/power/cooling
> > > issues
> >
> > Doesn't an MCE also cover some hardware memory problems - parity/ECC
> > issues etc?
>
> Parity/ECC on main memory is reported by the chipset and needs sepera
On Wed, 31 Jan 2001, Richard B. Johnson wrote:
> On Wed, 31 Jan 2001, Rik van Riel wrote:
> > On Wed, 31 Jan 2001, Richard B. Johnson wrote:
> > > On Tue, 30 Jan 2001, Rik van Riel wrote:
> > > > On Tue, 30 Jan 2001, Richard B. Johnson wrote:
> > > >
> > > > > The subject says it all. `make dep`
On Tue, 30 Jan 2001, Timur Tabi wrote:
> ** Reply to message from Christopher Neufeld <[EMAIL PROTECTED]> on Tue, 30
> Jan 2001 16:08:32 -0800
>
>
> > Would it be possible to bump it up to 128, or even
> > 256, in later 2.4.* kernel releases? That would allow this customer to
> > work with an
On Mon, 29 Jan 2001, List User wrote:
> Just wanted to 'chime' in here. Yes this would be noisy and will have
> an affect on system performance however these statistics are what are
> used in conjunction with several others to size systems as well as to
> plan on growth. If Linux is to be put i
On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
> > On Sun, 28 Jan 2001, jamal wrote:
> > > There were people who made the suggestion that TCP should retry after a
> > > RST because it "might be an anti-ECN path"
> >
&
On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> James Sutherland <[EMAIL PROTECTED]> wrote:
> >On Sun, 28 Jan 2001, jamal wrote:
> >> The internet is a form of organized chaos, sometimes you gotta make
> >>
On Sun, 28 Jan 2001, Ben Ford wrote:
> James Sutherland wrote:
>
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
> >
> > The o
On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
>
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
>
> The em
On 27 Jan 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]>
> wrote:
> >
> >We've narrowed it down to "we're all running xmms" when it happend.
>
> Does anybody have a clue about what is different with xmms?
>
> Does it use KNI if it can, for example?
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make, though, is that firewalls are NOT
"brain-damaged" for blocking ECN: according to the RFCs governing
firewalls,
On Sat, 27 Jan 2001, Gregory Maxwell wrote:
> On Sat, Jan 27, 2001 at 11:09:27PM +0000, James Sutherland wrote:
> > On Sat, 27 Jan 2001, David Schwartz wrote:
> >
> > >
> > > > Firewalling should be implemented on the hosts, perhaps with centralized
On Sat, 27 Jan 2001, David Schwartz wrote:
>
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
>
> That's madness. If you have to implement your firewalling o
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T16:04:03,
>"Randal, Phil" <[EMAIL PROTECTED]> said:
>
> > We may be right, "they" may be wrong, but in the real world
> > arrogance rarely wins anyone friends.
>
> So you also turn of PMTU and just set the MTU to 200 bytes becau
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T15:08:21,
> James Sutherland <[EMAIL PROTECTED]> said:
>
> > Obviously. The connection is now dead. However, trying to make a new
> > connection with different settings is perfectly reasonable.
>
&g
On Fri, 26 Jan 2001, David S. Miller wrote:
> James Sutherland writes:
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connecti
On Fri, 26 Jan 2001, David S. Miller wrote:
>
> James Sutherland writes:
> > A delayed retry without ECN might be a good compromise...
> >
> > Every single connection to ECN-broken sites would work as normal - it
> > would just take an extra few second
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T11:40:36,
> James Sutherland <[EMAIL PROTECTED]> said:
>
> > A delayed retry without ECN might be a good compromise...
>
> _NO!_
Why? As it stands, I have ECN disabled. It's staying disabled
On Fri, 26 Jan 2001, David S. Miller wrote:
>
> Matti Aarnio writes:
> > But could you nevertheless consider supplying a socket option for it ?
> > By all means default it per sysctl, but allow clearing/setting by
> > program too.
>
> No, because then people will do the wrong thing.
>
On Thu, 25 Jan 2001, David S. Miller wrote:
> Some of the MX records that show up for hotmail.com go
> to different machines, such as INKY.SOLINUS.COM which seems
> to let ECN connections through just fine.
Ahh.. In which case, *@hotmail.com list subscribers should still get their
mail OK - it w
On Thu, 25 Jan 2001, David S. Miller wrote:
>
> Andi Kleen writes:
> > It's mostly for security to make it more difficult to nuke connections
> > without knowing the sequence number.
> >
> > Remember RFC is from a very different internet with much less DoS attacks.
>
> Andi, one of the wor
On Thu, 25 Jan 2001, Matthias Andree wrote:
> On Wed, 24 Jan 2001, Andi Kleen wrote:
>
> > It's mostly for security to make it more difficult to nuke connections
> > without knowing the sequence number.
> >
> > Remember RFC is from a very different internet with much less DoS attacks.
>
> If y
On Thu, 25 Jan 2001, bert hubert wrote:
> On Thu, Jan 25, 2001 at 09:06:33AM +0000, James Sutherland wrote:
>
> > performance than it would for an httpd, because of the long-lived
> > sessions, but rewriting it as a state machine (no forking, threads or
> > other crap, j
On Thu, 25 Jan 2001, Alan Cox wrote:
> > I was wondering if someone could tell me where I can find
> > Xeon Pentium III cpu error messages/codes
>
> In the intel databook. Generally an MCE indicates hardware/power/cooling
> issues
Doesn't an MCE also cover some hardware memory problems - parity
On Thu, 25 Jan 2001, Alan Cox wrote:
> > I think, that is not what we need. Once Ingo wrote, that since HTTP
> > serving can also be viewed as a kind of fileserving, it should be
> > possible to create a TUX like module for the same framwork, that serves
> > using the SMB protocol instead of H
On Wed, 24 Jan 2001, Sasi Peter wrote:
> > AIUI, Jeff Merkey was working on loading "userspace" apps into the
> kernel
> > to tackle this sort of problem generically. I don't know if he's
> tried it
> > with Samba - the forking would probably be a problem...
>
> I think, that is not what we ne
On Wed, 24 Jan 2001, Sasi Peter wrote:
> On 14 Jan 2001, Linus Torvalds wrote:
>
> > The only obvious use for it is file serving, and as high-performance
> > file serving tends to end up as a kernel module in the end anyway (the
> > only hold-out is samba, and that's been discussed too), "sendfi
On Tue, 23 Jan 2001, Helge Hafting wrote:
> James Sutherland wrote:
> >
> > On Mon, 22 Jan 2001, Helge Hafting wrote:
> >
> > > And when the next user wants the same webpage/file you read it from
> > > the RAID again? Seems to me you loose the benefit of
On Mon, 22 Jan 2001, Helge Hafting wrote:
> And when the next user wants the same webpage/file you read it from
> the RAID again? Seems to me you loose the benefit of caching stuff in
> memory with this scheme. Sure - the RAID controller might have some
> cache, but it is usually smaller than mai
On Sat, 20 Jan 2001, Linus Torvalds wrote:
>
>
> On Sat, 20 Jan 2001, Roman Zippel wrote:
> >
> > On Sat, 20 Jan 2001, Linus Torvalds wrote:
> >
> > > But point-to-point also means that you don't get any real advantage from
> > > doing things like device-to-device DMA. Because the links are
> > >
On Sun, 21 Jan 2001, Lincoln Dale wrote:
> hi,
>
> At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote:
> >[EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in
> ><[EMAIL PROTECTED]>:
> > > i'm pretty sure the actual use of pipelining is pretty disappointing.
> > > the work i did in apache preced
On Sat, 4 Nov 2000, Albert D. Cahalan wrote:
> Dominik Kubla writes:
> > On Fri, Nov 03, 2000 at 11:33:10AM -0800, H. Peter Anvin wrote:
>
> [about IBM's JFS and ext3 both wanting to put code in fs/jfs]
>
> >> How about naming it something that doesn't end in -fs, such as
> >> "journal" or "jfs
On Sun, 29 Oct 2000, Jesse Pollard wrote:
> On Sun, 29 Oct 2000, Stephen Harris wrote:
> >Horst von Brand wrote:
> >
> >> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> >> > > kernel 2.2.x), within a few minutes you will find your entire machine
> >> > > grinds to a ha
On 29 Oct 2000, Eric W. Biederman wrote:
> Raul Miller <[EMAIL PROTECTED]> writes:
>
> > Can anyone tell me about the viability of a guarantee_memory() syscall?
> >
> > [I'm thinking: it would either kill the process, or allocate all virtual
> > memory needed for its shared libraries, buffers,
On Fri, 27 Oct 2000, David Schwartz wrote:
>
> > Now, if a module is loaded that registers a set of functions that have
> > increased functionality compared to the original functions, if that
> > modules is not based off GPL'd code, must the source code of that module
> > be released under the G
On Mon, 23 Oct 2000 [EMAIL PROTECTED] wrote:
> In the words of Barry K. Nathan :
>
> > > Why they didn't call it K6-4 is anyones guess.
> > I read somewhere (I don't have a URL handy, sorry) that the reason AMD
> > went with K6-2+ is that, apparently, the K6-2 name is well-known, and
> > they wa
On Tue, 17 Oct 2000, Werner Almesberger wrote:
> Marc MERLIN wrote:
> > Come on, Andi, it's not. You do DAD, you get your IP, I plug my laptop, use
> > your IP, you don't even know it. My patch lets you know.
> > The reason I wrote it is that I've seen this happen too many times already.
>
> Als
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > > so dns helper is killed first, then netscape. (my idea might not
> > > make sense though.)
> >
> > It makes some sense, but I don't think OOM is something that
> > occurs often enough to care about it /that
On Fri, 29 Sep 2000, Daniel Phillips wrote:
> Marty Fouts wrote:
> > My own opinion is that no, the nominal cost of standards documents has
> > little to do with why programmers don't have complete and up to date
> > definitions of the language.
>
> I can't change your opinion but I can tell you
On Wed, 27 Sep 2000, David Ford wrote:
> James Sutherland wrote:
>
> > No. I am assuming you are installing the kernel on the machine you do
> > "make modules_install" on. Obviously it is possible to install a different
> > kernel image of the same version wit
On Wed, 27 Sep 2000, Butter, Frank wrote:
> > How about putting these files in the modules directory? That
> > way, we have
> > a nice consistent location for them.
> > /lib/modules/`uname -r`/build/System.map etc. is a fair
> > approximation, but
> > you lose that every time the kernel source
On Tue, 26 Sep 2000, Thomas Zehetbauer wrote:
> > But if you can get rid of the stacks, and you _can_ get rid of the
> > stacks sometimes, then why not have one thread per widget in a GUI? Or
> > one thread per animated objected on a web page? Some notions of
> For this to work without opening
On Mon, 25 Sep 2000, Russell King wrote:
> James Sutherland writes:
> > On Sat, 23 Sep 2000, Russell King wrote:
> > > And I'll try to make the point a second time that everything does not have
> > > a character-based screen to write to.
> >
> > So wh
On Sat, 23 Sep 2000, Russell King wrote:
> Keith Owens writes:
> > Something I forgot to mention about debugging using screen writes. If
> > the problem is caused by incorrect compiler output then even printk can
> > fail. Not because the C code is wrong but because the generated
> > assembler
On Sat, 23 Sep 2000, Keith Owens wrote:
> On Sat, 23 Sep 2000 11:33:31 +0200,
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> >I'd just like to remind you of Alan Cox's suggestion about appending
> >.config.gz to bzImage so that it doesn't get loaded into memory, and
> >my suggestion to put Syste
On Wed, 20 Sep 2000, Marco Colombo wrote:
> On Wed, 20 Sep 2000, Simon Richter wrote:
>
> > Hi,
> >
> > I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit
> ^^
> isn't it overclocked?
>From the CPU identification given later, it is sai
On Sun, 17 Sep 2000, Evan Jeffrey wrote:
>
> > > 1. The inactive_target is 1 second worth of allocations, minus
> > >the amount of frees in 1 second, averaged over a minute
> >
> > So it cannot take load bursts. That's ok for a default, but for special loads
> > it would be good if there wa
On Sat, 16 Sep 2000, Giuliano Pochini wrote:
> I wrote, then got air-brushed out of the thread?!
> > That's one approach; I prefer my "weighted scoring" approach. Supposing we
> > have three devices: a solid state disk (instant "seeks"), a hard drive and
> > a tape. The SSD will benefit from merg
On Wed, 13 Sep 2000, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> This (IMHO) is wrong. When the drive has trouble keeping up
> with requests in FCFS order, we should do some elevator sorting
> to keep throughput high enough to deal with the requests we get.
Reversing that
On Wed, 13 Sep 2000, Andrea Arcangeli wrote:
> On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
>
> >The "large queue" goes against the whole point of this exercise - that
> >is that if there are many items in the "queue" being sorted then
> >unlucky requests can end up waiting a long time to get s
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> James Sutherland wrote:
> > In terms of latency, I'd suggest we aim to keep the device in use all the
> > time we have outstanding requests: every time the device is ready to
> > accept a request, we feed it the "next
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> Alan Cox wrote:
> > > Yes, but "how hard is it reasonable for the kernel to try" is based on
> > > both items. A good first order approximation is number of requests.
> >
> > I must strongly disagree with that claim. A request could be 512 bytes o
87 matches
Mail list logo
