Re: [PATCH] x86: add PCI IDs to k8topology_64.c II

On Tue, 29 Jan 2008, Andi Kleen wrote: > > SRAT is essentially just a two dimensional table with node distances. > > Sorry, that was actually SLIT. SRAT is not two dimensional, but also > relatively simple. SLIT you don't really need to implement. yeah but i'd heartily recommend implementing SLI

Re: [PATCH 2.6.24] x86: add sysfs interface for cpuid module

why do we need another kernel cpuid reading method when sched_setaffinity exists and cpuid is available in ring3? -dean -- 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

Re: system without RAM on node0 boot fail

actually yeah i've seen this... in a bizarre failure situation in a system which physically had RAM in the boot node but it was never enumerated for the kernel (other nodes had RAM which was enumerated). so technically there was boot node RAM but the kernel never saw it. -dean On Wed, 30 Jan 2

Re: Broken ARP (was Re: ARP responses broken!)

On Tue, 17 Apr 2001, Eric Weigle wrote: > Ok, I was ignorant of the arp filter functionality in 2.2. I found an old > (probably painfully out-of-date) posting the patch Andi Kleen was referring to > in the archive, but I've not used it. > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/

Re: ARP out the wrong interface

On Fri, 9 Feb 2001, Matthew Kirkwood wrote: > On Thu, 8 Feb 2001, dean gaudet wrote: > > > responses come back from both eth0 and eth1, listing each of their > > respective MAC addresses... it's essentially a race condition at this > > point as to whether i

Re: strange nonmonotonic behavior of gettimeoftheday -- seen similar problem on PPC

On Fri, 2 Mar 2001, Richard B. Johnson wrote: > Note that two subsequent calls to gettimeofday() must not return the > same time even if your CPU runs infinitely fast. I haven't seen any > kernel in the past few years that fails this test. i don't see any requirement for this in SuS. http://www

Re: scsi vs ide performance on fsync's

On Tue, 6 Mar 2001, Jonathan Morton wrote: > Pathological shutdown pattern: assuming scatter-gather is not allowed > (for IDE), and a 20ms full-stroke seek, write sectors at alternately > opposite ends of the disk, working inwards until the buffer is full. > 512-byte sectors, 2MB of them, is 400

Re: scsi vs ide performance on fsync's

On Tue, 6 Mar 2001, dean gaudet wrote: > i assume you meant to time the xlog.c program? (or did i miss another > program on the thread?) > > i've an IBM-DJSA-210 (travelstar 10GB, 5411rpm) which appears to do > *something* with the write cache flag -- it gets 0.10s el

storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,2.4.0-1)

On Tue, 9 Jan 2001, Ingo Molnar wrote: > On Mon, 8 Jan 2001, Rik van Riel wrote: > > > Having proper kiobuf support would make it possible to, for example, > > do zerocopy network->disk data transfers and lots of other things. > > i used to think that this is useful, but these days it isnt. this

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networkingpatch, 2.4.0-1)

On Tue, 9 Jan 2001, David S. Miller wrote: >Date: Tue, 9 Jan 2001 18:56:33 -0800 (PST) >From: dean gaudet <[EMAIL PROTECTED]> > >is NFS receive single copy today? > > With the zerocopy patches, NFS client receive is "single cpu copy" if > that&

Re: Poll and Select not scaling

On Wed, 10 Jan 2001, Dan Kegel wrote: > select() is usually limited to 1024 file descriptors oh hey, this limit is only a libc limit these days. you can do this: #define MY_FD_SETSIZE (16384) typedef struct { __fd_mask __fds_bits[MY_FD_SETSIZE / __NFDBITS]; } my_fd_set; #define MY_FD_Z

Re: khttpd beats boa with persistent patch

a few comments... - localhost is a meaningless benchmark. it's useful to catch some low hanging fruit, but it really doesn't help in the long run. - contrast the max connection times between kHTTPd and Boa. if that 9 second maximum for kHTTPd is any indication of its latency performance on a r

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: > (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to > Linux is sendpath(), which does the open() before the sendfile() > all combined into one system call. how would sendpath() construct the Content-Length in the HTTP header? it's

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: > > TCP_CORK is useful for FAR more than just sendfile() headers and > > footers. it's arguably the most correct way to write server code. > > Agreed -- the hard-coded Nagle algorithm makes no sense these days. hey, actually a little more thinking

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

On Mon, 15 Jan 2001, Ingo Molnar wrote: > just for kicks i've implemented sendpath() support. > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) hey so how do you implement transmit timeouts with sendpath() ? (i.e. drop the client after 30 seconds of no progres

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

On Tue, 16 Jan 2001, Ingo Molnar wrote: > > On Mon, 15 Jan 2001, dean gaudet wrote: > > > > just for kicks i've implemented sendpath() support. > > > > > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) > > > &g

Re: 'native files', 'object fingerprints' [was: sendpath()]

On Tue, 16 Jan 2001, Ingo Molnar wrote: > But even user-space code could use 'native files', via the following, safe > mechanizm: so here's an alternative to ingo's proposal which i think solves some of the other objections raised. it's something i've proposed in the past under the name "extend

Re: Is sendfile all that sexy?

On Tue, 16 Jan 2001, David L. Parsley wrote: > Felix von Leitner wrote: > > > close (0); > > > close (1); > > > close (2); > > > open ("/dev/console", O_RDWR); > > > dup (); > > > dup (); > > > > So it's not actually part of POSIX, it's just to get around fixing > > legacy code? ;-)

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > > The fact that I understand _why_ it is done that way doesn't mean that I > > don't think it's a hack. It doesn't allow you to sendfile multiple files > > etc without having nagle boundaries, and the header/trailer stuff really > > isn't a generic solutio

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > > actually the problem isn't nagle... nagle needs to be turned off for > > efficient servers anyhow. > > i'm not sure I follow that. could you expand on that a bit? the problem which caused us to disable nagle in apache is documented in this paper

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

hasn't been finalised (because they're being pretty ambitious); and nobody has decided to just forge forward and layer HTTP/1.1 on top of WebMUX yet. (the subversive in me wants to see WebMUX patches for apache, squid, and mozilla ;) -dean On Thu, 18 Jan 2001, dean gaudet wrote:

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Zach Brown wrote: > We set TCP_CORK on the socket we handed to external programs that were > being run via 'site exec' in an ftp server. It resulted in much nicer > packets being spit out, especially in the 'ls' case where it likes to > write() on really goofy boundaries. >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

huh -- i think with this apache could solve the problem documented in heidemann's paper while also leaving nagle on... which would solve the CGI dribbler vs. bulk problem i just posted about. at the end of a request apache would check first if it can get another request without blocking; if it wo

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

n that's sweet. now if only i had a portable version of this :) -dean On Thu, 18 Jan 2001, dean gaudet wrote: > huh -- i think with this apache could solve the problem documented in > heidemann's paper while also leaving nagle on... which would solve the CGI > dribbler vs. bulk

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On 20 Jan 2001, 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 preceded the widespread use of HTTP/1.1 a

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

On Sat, 4 Nov 2000, Andrew Morton wrote: > Dean, > > neither flock() nor fcntl() serialisation are effective > on linux 2.2 or linux 2.4. i have to admit the last time i timed any of the methods on linux was in 2.0.x days. thanks for the updated data! > For kernel 2.2 I recommend that Apache

Re: [PATCH] Re: Negative scalability by removal of

Date: Mon, 6 Nov 2000 21:23:57 -0800 (PST) > From: dean gaudet <[EMAIL PROTECTED]> > > apache is about correctness first, and performance second. > > Which is why we say it is "incorrect" for apache to try > and work around kernel performance pro

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange

On Sat, 4 Nov 2000, Alan Cox wrote: > > sysv semaphores have a very unfortunate negative feature -- if the admin > > kill -9's the server (impatient admins do this all the time) then you end > > up leaving a semaphore lying around. sysvsem don't have the usual unix > > Umm they have SEM_UNDO. I

Re: [PATCH] Fix disk statistic reporting to include all disks

On Tue, 29 Aug 2000, Linus Torvalds wrote: > On Wed, 30 Aug 2000, Jens Axboe wrote: > > > On Wed, Aug 30 2000, Jens Axboe wrote: > > > Sounds sane, but what about drivers that don't really use the request > > > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > > > lru_list

Re: thread rant

On Fri, 1 Sep 2000, Michael Bacarella wrote: > Q: Why do we need threads? > A: Because on some operating systems, task switches are expensive. maybe this problem will help you understand threads better: design a webserver which supports SSL session keys. consider the performance of you

Re: thread rant

On Fri, 1 Sep 2000, Mike A. Harris wrote: > I've heard comments from Alan, and others in the past bashing > threads, and I can understand the "threads are for people who > can't write state machines" comments I've heard, but what other > ways are there of accomplishing the goals that threads solv

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > > On Fri, 1 Sep 2000, dean gaudet wrote: > > > yup you can do this without threads. apache-1.3+mod_ssl for example. > > > > but it's not fun, and it's a lot more work on the portability side. > > in

Re: thread rant

On Sat, 2 Sep 2000, Alexander Viro wrote: > *threads* *are* *hard* *to* *write* *correctly* in C, yes that can be essentially true. although you can do a webserver with no mutexes pretty easily... the first threaded apache had exactly one mutex -- inside the memory allocator when it had t

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > i dont understand why this is such an important category. If the sharing > is very high between the threads then it makes sense to use 'shared-all > threads'. But frequently the example given are webservers, which often do > not have alot of cross-request

Re: zero-copy TCP

On Mon, 4 Sep 2000, Linus Torvalds wrote: > On Mon, 4 Sep 2000, Jamie Lokier wrote: > > > Linus Torvalds wrote: > > > > > Basically any copy <= 4 cache lines is "free" compared to trying to be > > > clever. > > > > We're obviously interested in larger packets than 128 bytes. > > "obviously"?

O_CLOEXEC (was Re: thread rant)

On Sat, 2 Sep 2000, Alexander Viro wrote: > On Sat, 2 Sep 2000, Jamie Lokier wrote: > > > dean gaudet wrote: > > > an example of brokenness in the traditional fd API is close-on-exec -- > > > there's a race between open()/socket()/pipe() and fcntl(FD_CLO

Re: zero-copy TCP

On Mon, 4 Sep 2000, Jamie Lokier wrote: > Alan Cox wrote: > > > It's not faster than card->card DMA, which falls out naturally from my > > > zero-copy proposal :-) > > > > We already support card->card DMA for routing with fastrouting > > ..but not for user space proxies which was the above's c

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

On Sun, 3 Sep 2000, Andre Hedrick wrote: > But there is no Copyright license in patch code. On Mon, 4 Sep 2000, Mike A. Harris wrote: > I was under the understanding a "patch" to something GPL, means > the "patch" is also GPL. when IBM started working with the apache group their lawyers did a

Re: GPL violations: make it harder

On Tue, 5 Sep 2000, Mike A. Harris wrote: > If even one file in the kernel source gets modified, then the entire > patch is GPL via the GPL assimilation rules in COPYING - regardless of > what the author of the patch says. IANAL. i know this is what the GPL wants, but AFAIK it's never been test

Re: GPL violations: make it harder

On Tue, 5 Sep 2000, Jeff Epler wrote: > strings plus code that I wrote. (My actual desire was to figure out a way > that I could release QuakeC modifications under the GPL, when the base > QuakeC source was not GPL. I hope there's no ethical brown stuff involved > in that desire!) assuming you

Re: GPL violations: make it harder

sorry i should have pointed to this in my previous response -- read if you haven't already. (really wish i knew more about these topics outside the US... i'm even naive regarding these laws in my own home country Canada.) -dean - To unsubscribe from this list:

Re: Availability of kdb

On Wed, 6 Sep 2000, Alan Cox wrote: > In many ways good crash dump tools and tracebacks (oopses do not count) are > the valuable bit - remote gdb happens to be a passable crash dump tool if you're lucky and can analyse the crash online, maybe. but offline crash dump analysis is the only option

Re: Linux-2.4.0-test8-pre6

On Wed, 6 Sep 2000, Linus Torvalds wrote: > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > fixed it now several times, and I was always wrong. obpainintheass: haven't you anti-debugger-religion folks been claiming that if you don't have a debugger you're forced to "t

Re: Linux-2.4.0-test8-pre6

On Thu, 7 Sep 2000, Bill Wendling wrote: > Also sprach dean gaudet: > } On Wed, 6 Sep 2000, Linus Torvalds wrote: > } > } > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > } > fixed it now several times, and I was always wrong. > }

Re: 2.2 generating odd TCP resets?

On Wed, 18 Oct 2000, Brian Craft wrote: > In the code below, I removed the shutdown() and added the block > after do_scan() to eliminate the RST. The read() never finds any data. > If there's no data pending, why does read() have any affect? EOF is considered pending data... and has to be read.

Re: select() bug

> > Semantic issues aside, since Apache does the test I mentionned earlier > > to determine child status and since it could be misled, should this > > feature be turned off? > > Or made smarter yes i'm scratching my head wondering what i was thinking when i wrote that code. the specific thing t

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote: > I don't mean this to sound like a rant. It's just that I can't possibly > ascertain why someone in their right mind would want any behaviour > different than SA_RESTART. study apache 1.3's child_main code, you'll see an example of EINTR in use. it

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

On Fri, 3 Nov 2000, Linus Torvalds wrote: > Please use unserialized accept() _always_, because we can fix that. i can unserialise the single socket case, but the multiple socket case is not so simple. the executive summary is that when you've got multiple sockets you have to use select(). sele

Re: [PATCH] Re: Negative scalability by removal of

the numbers didn't look that bad for the small numbers of concurrent clients on 2.2... a few % slower without the serialisation. compared to orders of magnitude slower with large numbers of concurrent client. oh, someone reminded me of the other reason sysvsems suck: a cgi can grab the semaphor

Re: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...

On Mon, 6 Nov 2000, George Talbot wrote: > I respectfully disagree that programs which don't surround some of the > most common system calls with > > do > { > rv = __some_system_call__(...); > } while (rv == -1 && errno == EINTR); welcome to Unix. this is how it

Re: [PATCH] Re: Negative scalability by removal of

On Mon, 6 Nov 2000, Linus Torvalds wrote: > This is why I'd love to _not_ see silly work-arounds in apache hey, maybe it's time for me to repeat something that i'm often quoted as saying: apache is about correctness first, and performance second. i don't think that's silly personally. remem

Re: how to capture long oops w/o having second machine

i've always been curious why none of the crash dump patches are default. an oops dumper alone would seem to be most useful. (i know anything more would be unacceptable 'cause linus isn't into debuggers ;) -dean On Tue, 12 Dec 2000, Miles Lane wrote: > > Try reading: > > http://www.linuxh

Re: linux 2.2.19pre and thttpd (VM-global problem?)

On Fri, 29 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has > > superb scaling properties compared to say apache. > > I think with 8 CPUs and 8 NICs (usual benchmark setup) y

dentry cache order 7 is broken

this looks to be a problem going back all the way to at least 2.2. if you've got 512Mb of RAM you end up with a dentry cache of order 7 -- 65536 entries. this results in a D_HASHBITS of 16. if you look at d_hash it contains this code: hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HAS

Re: dentry cache order 7 is broken

that appears to do it :) -dean On Thu, 8 Feb 2001, David S. Miller wrote: > > dean gaudet writes: > > also, for order > 7, was the real intention to use a shift of > > (order*2)&31? > > No, the whole thing is buggered. How stupid, my fault. > It was t

ARP out the wrong interface

this appears to occur with both 2.2.16 and 2.4.1. server: eth0 is 192.168.250.11 netmask 255.255.255.0 eth1 is 192.168.251.11 netmask 255.255.255.0 they're both connected to the same switch. client: eth0 is 192.168.251.11 netmask 255.255.255.0 connected to the same switch as both of server's

Re: ARP out the wrong interface

oops typo. On Thu, 8 Feb 2001, dean gaudet wrote: > this appears to occur with both 2.2.16 and 2.4.1. > > server: > > eth0 is 192.168.250.11 netmask 255.255.255.0 > eth1 is 192.168.251.11 netmask 255.255.255.0 > > they're both connected to the same switch. > >

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

another possibility for a debugging mode for the kernel would be to hack gcc to emit something like the following in the prologue of every function (after the frame is allocated): movl %esp,%edx andl %edx,0x1fff cmpl %edx,sizeof(struct task)+512 jbe stack_overflow

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

On Fri, 25 May 2001, Andi Kleen wrote: > On Fri, May 25, 2001 at 04:03:57PM +0200, Oliver Neukum wrote: > > Is there a reason for the task structure to be at the bottom rather than the > > top of these two pages ? > > This way you save one addition for every current access; which adds to > quite

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

On Sat, 26 May 2001, Keith Owens wrote: > On Fri, 25 May 2001 08:31:24 -0700 (PDT), > dean gaudet <[EMAIL PROTECTED]> wrote: > >another possibility for a debugging mode for the kernel would be to hack > >gcc to emit something like the following in the prologue of ever

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

On Fri, 25 May 2001, Jonathan Lundell wrote: > At 8:45 AM -0700 2001-05-25, dean gaudet wrote: > >i think it really depends on how you use current -- here's an alternative > >usage which can fold the extra addition into the structure offset > >calculations, and moves

Re: select() - Linux vs. BSD

On Tue, 29 May 2001, John Chris Wren wrote: > In BSD, select() states that when a time out occurs, the bits passed to > select will not be altered. from the single unix standard: On failure, the objects pointed to by the readfds, writefds, and errorfds arguments are not mo

Re: POSIX/1003.b/whatever docs free?

if you go to opengroup.org you can read the single-unix standard for free... you need to register though. (it's not quite the same as POSIX...) -dean On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > Is there somewhere I can download the collection of POSIX standards docs > free of charge? > > ;-

Re: Break 2.4 VM in five easy steps

On Wed, 6 Jun 2001, Dr S.M. Huen wrote: > If you can afford 4GB RAM, you certainly can afford 8GB swap. this is a completely crap argument. you should study the economics of managing a farm of thousands of machines some day. when you do this, you'll also learn to consider the power requirement

Re: Break 2.4 VM in five easy steps

On Wed, 6 Jun 2001, Alexander Viro wrote: > On Wed, 6 Jun 2001, Sean Hunter wrote: > > > This is completely bogus. I am not saying that I can't afford the swap. > > What I am saying is that it is completely broken to require this amount > > of swap given the boundaries of efficient use. > > Funny

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote: > > "My expectation is if we want to beat the competition, we'll want > > the ability to go *under* 100Hz." > > What does Windows do here? windows xp base rate is 100Hz... but multimedia a

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote: > > > windows xp base rate is 100Hz... but multimedia apps can ask for > > almost any rate they want (depends on the hw capabilities). i > > recall seeing rates >

Re: Question about SO_LINGER

On Wed, 10 Aug 2005, steve roussey wrote: > socket to shut down. Apache has a workaround called lingering_close() > that tries to address broken SO_LINGER implementations, but it also blocks." apache 1.x is single threaded / forked, so yeah it blocks. the implementation is there because very f

Re: IBM HDAPS things are looking up

On Mon, 4 Jul 2005, Alejandro Bonilla wrote: >Do you think that the kernel will STOP, HOLD and park the head in less than > a second? OR on the time we need? this is why the windows driver uses heuristics to decide when the laptop is possibly unstable and *may* fall soon... because it takes

Re: Power consumption HZ250 vs. HZ1000

On Mon, 25 Jul 2005, Marc Ballarin wrote: > Hmm, just did. I even tried the rather minimalistic configuration below. > Still no C3. (And what seems even stranger: no C1.) there's no point to going into C1 if the C2 entry/exit latencies are acceptable. (winxp generally never uses C1 if C2 is ava

Re: zero-copy read() interface

On Thu, 18 Aug 2005, Folkert van Heusden wrote: > Doesn't that one also use copying? I've also heard that using mmap is > expensive due to pagefaulting. I've found, for example, that copying a > 1.3GB file using read/write instead of mmap & memcpy is seconds faster. why would you memcpy if you're

dying disk results in unusable system

hi... i've run into this a bunch of times, but decided to look at it more closely today. i use IDE disks in md raid1 and/or raid5, and when one disk is dying or dead it tends to make the entire system unusable. i don't really fault md here, because i'm pretty sure there are some fundamental p

Re: RFC: i386: kill !4KSTACKS

On Mon, 5 Sep 2005, Adrian Bunk wrote: > How do you put pressure on hardware manufacturers for getting them to > release the specs? > > If they are able to write "supported by Linux" on their products anyway > because there's a driver that runs under NdisWrapper? that's specious... they can pu

Re: Fast network file copy; "recvfile()" ?

On Thu, 17 Jan 2008, Patrick J. LoPresti wrote: > I need to copy large (> 100GB) files between machines on a fast > network. Both machines have reasonably fast disk subsystems, with > read/write performance benchmarked at > 800 MB/sec. Using 10GigE cards > and the usual tweaks to tcp_rmem etc., I

Re: RFC: permit link(2) to work across --bind mounts ?

On Wed, 19 Dec 2007, David Newall wrote: > Mark Lord wrote: > > But.. pity there's no mount flag override for smaller systems, > > where bind mounts might be more useful with link(2) actually working. > > I don't see it. You always can make hard link on the underlying filesystem. > If you need t

Re: RFC: permit link(2) to work across --bind mounts ?

On Sat, 29 Dec 2007, Jan Engelhardt wrote: > > On Dec 28 2007 18:53, dean gaudet wrote: > >p.s. in retrospect i probably could have arranged it more like this: > > > > mount /dev/md1 $tmpmntpoint > > mount --bind $tmpmntpoint/var /var > > mount --bind

Re: RFC: permit link(2) to work across --bind mounts ?

On Sat, 29 Dec 2007, David Newall wrote: > dean gaudet wrote: > > On Wed, 19 Dec 2007, David Newall wrote: > > > > > Mark Lord wrote: > > > > > > > But.. pity there's no mount flag override for smaller systems, > > > > where

Re: RFC: permit link(2) to work across --bind mounts ?

On Sun, 30 Dec 2007, David Newall wrote: > dean gaudet wrote: > > > Pffuff. That's what volume managers are for! You do have (at least) two > > > independent spindles in your RAID1 array, which give you less need to > > > worry > > > about hea

Re: RFC: permit link(2) to work across --bind mounts ?

On Sat, 29 Dec 2007, [EMAIL PROTECTED] wrote: > On Sat, 29 Dec 2007 12:40:47 PST, dean gaudet said: > > > the main worry i have is some user maliciously hardlinks everything > > under /var/log somewhere else and slowly fills up the file system with > > old rotated logs

Re: [PATCHv3 0/4] sys_indirect system call

On Mon, 19 Nov 2007, Ingo Molnar wrote: > > * Eric Dumazet <[EMAIL PROTECTED]> wrote: > > > I do see a problem, because some readers will take your example as a > > reference, as it will probably sit in a page that > > google^Wsearch_engines will bring at the top of search results for > > nex

Re: [patch][v2] x86, ptrace: support for branch trace store(BTS)

On Tue, 20 Nov 2007, dean gaudet wrote: > On Tue, 20 Nov 2007, Metzger, Markus T wrote: > > > +__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c) > > +{ > > + switch (c->x86) { > > + case 0x6: > > + switch (c->x86_model) { >

Re: [patch][v2] x86, ptrace: support for branch trace store(BTS)

On Tue, 20 Nov 2007, Metzger, Markus T wrote: > +__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c) > +{ > + switch (c->x86) { > + case 0x6: > + switch (c->x86_model) { > +#ifdef __i386__ > + case 0xD: > + case 0xE: /* Pentium M */ > +

Re: [RFC] Documentation about unaligned memory access

On Fri, 23 Nov 2007, Alan Cox wrote: > Its usually faster if you don't misalign on x86 as well. i'm not sure if i agree with "usually"... but i know you (alan) are probably aware of the exact requirements of the hw. for everyone else: on intel x86 processors an access is unaligned only if it c

Re: [RFC] Documentation about unaligned memory access

On Fri, 23 Nov 2007, Arne Georg Gleditsch wrote: > dean gaudet <[EMAIL PROTECTED]> writes: > > on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16 > > bytes. the penalty is a mere 3 cycles if an access crosses the specified > > boundary. &

Re: CPA patchset

On Fri, 11 Jan 2008, Ingo Molnar wrote: > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Cached requires the cache line to be read first before you can write > > it. > > nonsense, and you should know it. It is perfectly possible to construct > fully written cachelines, without reading the cache

Re: CPA patchset

On Fri, 11 Jan 2008, dean gaudet wrote: > On Fri, 11 Jan 2008, Ingo Molnar wrote: > > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > Cached requires the cache line to be read first before you can write > > > it. > > > > nonsens

nosmp/maxcpus=0 or 1 -> TSC unstable

if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it still disables TSC :) Marking TSC unstable due to TSCs unsynchronized this is an opteron 2xx box which does have two cpus and no clock-divide in halt or cpufreq enabled so TSC should be fine with only one cpu. pretty sure

Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

d5_activate_delayed is only called at unplug time, never in > raid5. This seems to bring back the performance numbers. Calling it > in raid5d was sometimes too soon... > > Cc: "Dan Williams" <[EMAIL PROTECTED]> > Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

On Tue, 15 Jan 2008, Andrew Morton wrote: > On Tue, 15 Jan 2008 21:01:17 -0800 (PST) dean gaudet <[EMAIL PROTECTED]> > wrote: > > > On Mon, 14 Jan 2008, NeilBrown wrote: > > > > > > > > raid5's 'make_request' function calls generic_m

Re: Client receives TCP packets but does not ACK

On Sun, 17 Jun 2001, Dan Podeanu wrote: > Is there any logical reason why if, given fd is a connected, AF_INET, > SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); > to the peer, over a rather slow network (read modem, satelite link, etc), > the data gets lost (the remote rece

Re: Client receives TCP packets but does not ACK

On Mon, 18 Jun 2001, Jan Hudec wrote: > Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked? > (ie. how many bytes were acked). no, but it's not necessarily a useful number anyhow -- because it's possible that the remote end ACKd bytes but the ACK never arrives. so you c

Re: Client receives TCP packets but does not ACK

On Mon, 18 Jun 2001, Jonathan Morton wrote: > > > Btw: can the aplication somehow ask the tcp/ip stack what was > >actualy acked? > >> (ie. how many bytes were acked). > > > >no, but it's not necessarily a useful number anyhow -- because it's > >possible that the remote end ACKd bytes but the

Re: Client receives TCP packets but does not ACK

On Tue, 19 Jun 2001, Jonathan Morton wrote: > > > > > Btw: can the aplication somehow ask the tcp/ip stack what was > >> >actualy acked? > >> >> (ie. how many bytes were acked). > >> > > >> >no, but it's not necessarily a useful number anyhow -- because it's > >> >possible that the remote

TCP_DEFER_ACCEPT

i was digging around for info on TCP_DEFER_ACCEPT and found this claim in the thttpd mailing list archive: > Alexey Kuznestov mentioned to me that on SMP servers, this option may > not be desired as it creates a new contention point is this still the case? i haven't played with it yet, but i wa

Re: X15 alpha release: as fast as TUX but in user space (fwd)

nique in a post dated > Nov 17, even though I can't find the original. > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg13584.html > > Initiated by a post from (iirc) Dean Gaudet, we found out that > gettimeofday was one particular system call in the Apache fast pat

Re: X15 alpha release: as fast as TUX but in user space

On Sun, 29 Apr 2001, Fabio Riccardi wrote: > I can disable header caching and see what happens, I'll add an option > for this in the next X15 release. heh, well to be honest, i'd put the (permanent) caching of the Date header into the very slimy, benchmark-only trick category. (right up there a

Re: X15 alpha release: as fast as TUX but in user space

On Mon, 30 Apr 2001, Fabio Riccardi wrote: > Ok I fixed it, the header date timestamp is updated with every request. > > Performance doesn't seem to have suffered significantly (less than 1%). rad! > BTW: Don't call me slime, I wasn't trying to cheat, I just didn't know that > the date stamp wa

Re: X15 alpha release: as fast as TUX but in user space (fwd)

um, presumably this new magic page won't eliminate the old syscall entry points. so just use those for UML. -dean On Fri, 4 May 2001, Pavel Machek wrote: > Hi! > > > > > That means that for fooling closed-source statically-linked binary, > > > > > > If they are using glibc then you have the ri

Re: [PATCH] arp_filter patch for 2.4.4 kernel.

On Sat, 5 May 2001, David S. Miller wrote: > How difficult is it to compose netfilter rules that do this? what's the performance impact of doing that? i've got multiple ip networks on the same gigabit link... i'm pretty happy with this tiny patch i've posted before, which is not on any critica

Re: [PATCH] arp_filter patch for 2.4.4 kernel.

also -- isn't it kind of wrong for arp to respond with addresses from other interfaces? what if ip_forward is 0? or if there's some other sort of routing policy in effect? -dean On Sat, 5 May 2001, dean gaudet wrote: > i've got multiple ip networks on the same gigabit

  1   2   >