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: [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: [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: 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: [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: [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]>

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: 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

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: 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: 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, 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 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 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] 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: [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: [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: [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: [PATCHv2 4/4] first use of sys_indirect system call

On Fri, 16 Nov 2007, Ulrich Drepper wrote: > dean gaudet wrote: > > honestly i think there should be a per-task flag which indicates whether > > fds are by default F_CLOEXEC or not. my reason: third party libraries. > > Only somebody who thinks exclusively about appli

Re: [PATCHv2 4/4] first use of sys_indirect system call

you know... i understand the need for FD_CLOEXEC -- in fact i tried petitioning for CLOEXEC options to all the fd creating syscalls something like 7 years ago when i was banging my head against the wall trying to figure out how to thread apache... but even still i'm not convinced that extending

Re: perfmon2 merge news

On Fri, 16 Nov 2007, Andi Kleen wrote: > I didn't see a clear list. - cross platform extensible API for configuring perf counters - support for multiplexed counters - support for virtualized 64-bit counters - support for PC and call graph sampling at specific intervals - support for reading coun

Re: [perfmon] Re: [perfmon2] perfmon2 merge news

On Thu, 15 Nov 2007, Paul Mackerras wrote: > dean gaudet writes: > > > actually multiplexing is the main feature i am in need of. there are an > > insufficient number of counters (even on k8 with 4 counters) to do > > complete stall accounting or to get a general over

Re: [perfmon] Re: [perfmon2] perfmon2 merge news

On Wed, 14 Nov 2007, Andi Kleen wrote: > Later a syscall might be needed with event multiplexing, but that seems > more like a far away non essential feature. actually multiplexing is the main feature i am in need of. there are an insufficient number of counters (even on k8 with 4 counters) to d

Re: TCP_DEFER_ACCEPT issues

fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year: http://www.mail-archive.com/[EMAIL PROTECTED]/msg28916.html it's possible the final message in that thread is how we should define the behaviour, i haven't tried the TCP_SYNCNT idea though. -dean - To unsubscribe from th

Re: Interaction between Xen and XFS: stray RW mappings

On Sun, 21 Oct 2007, Jeremy Fitzhardinge wrote: > dean gaudet wrote: > > On Mon, 15 Oct 2007, Nick Piggin wrote: > > > > > >> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > >> because it generally has to invalidate TLBs on

Re: Interaction between Xen and XFS: stray RW mappings

On Mon, 15 Oct 2007, Nick Piggin wrote: > Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > because it generally has to invalidate TLBs on all CPUs. why is that? ignoring 32-bit archs we have heaps of address space available... couldn't the kernel just burn address space a

Re: Intel Memory Ordering White Paper

On Sat, 8 Sep 2007, Petr Vandrovec wrote: > dean gaudet wrote: > > On Sun, 9 Sep 2007, Nick Piggin wrote: > > > > > I've also heard that string operations do not follow the normal ordering, > > > but > > > that's just with respect to i

Re: Intel Memory Ordering White Paper

On Sun, 9 Sep 2007, Nick Piggin wrote: > I've also heard that string operations do not follow the normal ordering, but > that's just with respect to individual loads/stores in the one operation, I > hope? And they will still follow ordering rules WRT surrounding loads and > stores? see section 7.

Re: [patch 5/5] x86: Set PCI config space size to extended for AMD Barcelona

it's so very unfortunate the PCI standard has no feature bit to indicate the presence of ECS. FWIW in my testing on a range of machines spanning 7 or 8 years i could read config space reg 256... and get 0x when the device didn't support ECS, and get valid data when the device did suppor

Re: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD Fam10h

On Sun, 12 Aug 2007, Linus Torvalds wrote: > On Sun, 12 Aug 2007, Dave Jones wrote: > > > > This does make me wonder, why these weren't caught in -mm ? > > I'm worried that -mm isn't getting a lot of exposure these days. People do > run it, but I wonder how many.. andrew caught it in -mm and r

Re: TLB sizes among x86 CPUs?

http://sandpile.org/ On Wed, 18 Jul 2007, Rene Herman wrote: > Good day. > > Would anyone happen to have a list of TLB sizes for some selected x86{,-64} > CPUs? I know it goes from a few entries on a 386 to a lot on Opteron but I > have a real hard time finding specific data. > > Rene. > - > To

Re: [PATCH] hugetlbfs read() support

On Thu, 19 Jul 2007, Bill Irwin wrote: > On Thu, Jul 19, 2007 at 10:07:59AM -0700, Nishanth Aravamudan wrote: > > But I do think a second reason to do this is to make hugetlbfs behave > > like a normal fs -- that is read(), write(), etc. work on files in the > > mountpoint. But that is simply my o

Re: [RFT][PATCH v7] sata_mv: convert to new EH

On Wed, 18 Jul 2007, Pasi Kärkkäinen wrote: > What brand/model your sata_mv controller is? Would be nice to know to be > able to get a "known-to-work" one.. http://supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm -dean

Re: [RFT][PATCH v7] sata_mv: convert to new EH

On Thu, 12 Jul 2007, Jeff Garzik wrote: > dean gaudet wrote: > > On Thu, 12 Jul 2007, Jeff Garzik wrote: > > > > > dean gaudet wrote: > > > > oh very nice... no warnings on boot, and no warnings while i "dd > > > > if=/dev/sdX > > >

Re: [RFT][PATCH v7] sata_mv: convert to new EH

On Thu, 12 Jul 2007, Jeff Garzik wrote: > dean gaudet wrote: > > oh very nice... no warnings on boot, and no warnings while i "dd if=/dev/sdX > > of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read > > test. > > > > for lack

Re: [RFT][PATCH v7] sata_mv: convert to new EH

On Wed, 11 Jul 2007, Jeff Garzik wrote: > As before, this patch is against 2.6.22 with no other patches needed nor > applied. > > In this revision, interrupt handling was improved quite a bit, > particularly for EDMA. The WARNING in mv_get_crpb_status() goes away, > because that routine went awa

Re: [RFT][PATCH 2/2] sata_mv: convert to new EH (v5)

On Mon, 9 Jul 2007, Jeff Garzik wrote: > > This is the latest update of the sata_mv conversion to new EH. I'm > looking for testers, of two configurations: > > 2.6.22 + patch #1 (baseline) > 2.6.22 + patch #1 + this patch (sata_mv new EH) > > This patch contains a sm

Re: limits on raid

On Sun, 17 Jun 2007, Wakko Warner wrote: > What benefit would I gain by using an external journel and how big would it > need to be? i don't know how big the journal needs to be... i'm limited by xfs' maximum journal size of 128MiB. i don't have much benchmark data -- but here are some rough not

Re: limits on raid

On Sun, 17 Jun 2007, Wakko Warner wrote: > dean gaudet wrote: > > On Sat, 16 Jun 2007, Wakko Warner wrote: > > > > > When I've had an unclean shutdown on one of my systems (10x 50gb raid5) > > > it's > > > always slowed the system down when b

Re: limits on raid

On Sat, 16 Jun 2007, Wakko Warner wrote: > When I've had an unclean shutdown on one of my systems (10x 50gb raid5) it's > always slowed the system down when booting up. Quite significantly I must > say. I wait until I can login and change the rebuild max speed to slow it > down while I'm using i

Re: limits on raid

On Sat, 16 Jun 2007, David Greaves wrote: > Neil Brown wrote: > > On Friday June 15, [EMAIL PROTECTED] wrote: > > > > > As I understand the way > > > raid works, when you write a block to the array, it will have to read all > > > the other blocks

Re: [shm][hugetlb] Fix get_policy for stacked shared memory files

On Mon, 11 Jun 2007, Adam Litke wrote: > Here's another breakage as a result of shared memory stacked files :( > > The NUMA policy for a VMA is determined by checking the following (in the > order > given): > > 1) vma->vm_ops->get_policy() (if defined) > 2) vma->vm_policy (if defined) > 3) task

Re: [patch 7/8] fdmap v2 - implement sys_socket2

On Sat, 9 Jun 2007, Linus Torvalds wrote: > IOW, the most common case for libraries is not that they get invoced to do > one thing, but that they get loaded and then used over and over and over > again, and the _reason_ for wanting to have a file descriptor open may > well be that the library w

Re: 2.6.21 numa policy and huge pages not working

On Tue, 15 May 2007, William Lee Irwin III wrote: > On Tue, May 15, 2007 at 10:41:06PM -0700, dean gaudet wrote: > > prior to 2.6.21 i could "numactl --interleave=all" and use SHM_HUGETLB and > > the interleave policy would be respected. as of 2.6.21 it doesn't s

Re: [PATCH] Introduce O_CLOEXEC (take >2)

nice. i proposed something like this 8 or so years ago... the problem is that you've also got to deal with socket(2), socketpair(2), accept(2), pipe(2), dup(2), dup2(2), fcntl(F_DUPFD)... everything which creates new fds. really what is desired is fork/clone with selective duping of fds. i.e.

Re: 2.6.21 numa policy and huge pages not working

On Tue, 15 May 2007, William Lee Irwin III wrote: > On Tue, May 15, 2007 at 10:41:06PM -0700, dean gaudet wrote: > > prior to 2.6.21 i could "numactl --interleave=all" and use SHM_HUGETLB and > > the interleave policy would be respected. as of 2.6.21 it doesn't s

Re: [patch 43/69] i386: HPET, check if the counter works

ugh... do not send email before breakfast. do not send email before breakfast. nevermind :) -dean On Tue, 5 Jun 2007, dean gaudet wrote: > the HPET specification allows for HPETs with *much* lower resolution than > 50us. in fact Fmin is 10Hz iirc. (sorry to jump in so late, b

Re: [patch 43/69] i386: HPET, check if the counter works

the HPET specification allows for HPETs with *much* lower resolution than 50us. in fact Fmin is 10Hz iirc. (sorry to jump in so late, but i'm about a month behind on the list.) -dean On Mon, 21 May 2007, Chris Wright wrote: > -stable review patch. If anyone has any objections, please let us

Re: [PATCH, RFT, v4] sata_mv: convert to new EH

On Fri, 25 May 2007, Jeff Garzik wrote: > Already uncovered and fixed a few bugs in v3. > > Here's v4 of the sata_mv new-EH patch. you asked for test results with 2.6.21.3 ... that seems to boot fine, and i've tested reading from the disks only and it seems to be working fine. ditto for 2.6.22-

2.6.21 numa policy and huge pages not working

prior to 2.6.21 i could "numactl --interleave=all" and use SHM_HUGETLB and the interleave policy would be respected. as of 2.6.21 it doesn't seem to respect the policy on SHM_HUGETLB request. see test program below. output from pre-2.6.21: 2ab19620 interleave=0-3 file=/2\040(deleted) huge

Re: Raid 10 Problems?

On Mon, 5 Mar 2007, Marc Perkel wrote: > > --- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > > > > On Mar 4 2007 19:37, Marc Perkel wrote: > > >> > > >> -b internal -- seems like a good idea to speed > > up > > >> resynchronization. > > > > > >I'm trying to figure out what the default is.

Re: console scroll lock causes DOS

On Wed, 7 Feb 2007, Andy wrote: > If the scroll lock is on and there is a bunch of console output, the machine > will eventually stop responding to the network, until scroll lock is turned > off (at sometimes that doesn't even help). > > Easy test: > > hit scroll lock > do a few echo t > /proc/

Re: [patch] faster vgetcpu using sidt (take 2)

On Thu, 18 Jan 2007, Andi Kleen wrote: > > let me know what you think... thanks. > > It's ok, although I would like to have the file in a separate directory. cool -- do you have a directory in mind? and would you like this change as two separate patches or one combined patch? thanks -dean - T

Re: [patch] faster vgetcpu using sidt (take 2)

On Sat, 13 Jan 2007, dean gaudet wrote: > ok here is the latest rev of this patch (against 2.6.20-rc4). > > timings in cycles: > > baseline patchedbaseline patched > no cache no cachecache cache > k8 pre-revF21

[patch] faster vgetcpu using sidt (take 2)

situations. at compile time this patch detects if 0x1000 + (CONFIG_NR_CPUS<http://arctic.org/~dean/vgetcpu/> -dean Signed-off-by: dean gaudet <[EMAIL PROTECTED]> Index: linux/arch/x86_64/kernel/time.c === --- linux.orig

Re: O_DIRECT question

On Thu, 11 Jan 2007, Linus Torvalds wrote: > On Thu, 11 Jan 2007, Viktor wrote: > > > > OK, madvise() used with mmap'ed file allows to have reads from a file > > with zero-copy between kernel/user buffers and don't pollute cache > > memory unnecessarily. But how about writes? How is to do zero-co

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Thu, 11 Jan 2007, Andrew Morton wrote: > On Thu, 11 Jan 2007 03:04:00 -0800 (PST) > dean gaudet <[EMAIL PROTECTED]> wrote: > > > On Tue, 9 Jan 2007, Neil Brown wrote: > > > > > Imagine a machine with lots of memory - say 100Gig. > > > > i'

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Tue, 9 Jan 2007, Neil Brown wrote: > Imagine a machine with lots of memory - say 100Gig. i've had these problems on machines as "small" as 8GiB. the real problem is that the kernel will let millions of potential (write) IO ops stack up for a device which can handle only mere 100s of IOs per

Re: [patch] faster vgetcpu using sidt

On Sat, 6 Jan 2007, dean gaudet wrote: > below is a patch which improves vgetcpu latency on all x86_64 > implementations i've tested. > > Nathan Laredo pointed out the sgdt/sidt/sldt instructions are > userland-accessible and we could use their limit fields to tuck away

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Mon, 8 Jan 2007, H. Peter Anvin wrote: > I *definitely* support the concept that RDPMC 0 should could CPU cycles by > convention in Linux. unfortunately that'd be very limiting and annoying on core2 processors which have dedicated perf counters for clocks unhalted (actual vs. nominal), but o

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Fri, 5 Jan 2007, Jan Engelhardt wrote: > > On Jan 4 2007 17:48, H. Peter Anvin wrote: > > > >[i386] All Transmeta CPUs have constant TSCs > >All Transmeta CPUs ever produced have constant-rate TSCs. > > A TSC is ticking according to the CPU frequency, is not it? transmeta decided years befor

Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

On Wed, 3 Jan 2007, Andrew Morton wrote: > On Wed, 03 Jan 2007 22:56:07 -0800 (PST) > David Miller <[EMAIL PROTECTED]> wrote: > > > Note that the original rtorrent debian bug report was against 2.6.18 > > I think that was 2.6.18+debian-added-dirty-page-tracking-patches. i've seen it on a 2.6.18

[patch] faster vgetcpu using sidt

x27;ll be used in those situations. at compile time this patch detects if 0x1000 + (CONFIG_NR_CPUS<http://arctic.org/~dean/vgetcpu/> -dean Signed-off-by: dean gaudet <[EMAIL PROTECTED]> Index: linux/arch/x86_64/kernel/time.c ===

Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?

On Sat, 30 Dec 2006, Denis Vlasenko wrote: > I was experimenting with SSE[2] clear_page() which uses > non-temporal stores. That one requires 16 byte alignment. > > BTW, it worked ~300% faster than memset. But Andi Kleen > insists that cache eviction caused by NT stores will make it > slower in m

Re: 2.6.19 file content corruption on ext3

On Mon, 18 Dec 2006, Linus Torvalds wrote: > On Tue, 19 Dec 2006, Nick Piggin wrote: > > > > We never want to drop dirty data! (ignoring the truncate case, which is > > handled privately by truncate anyway) > > Bzzt. > > SURE we do. > > We absolutely do want to drop dirty data in the writeout

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Thu, 14 Dec 2006, Jan Beulich wrote: > >with the patch it boots perfectly without any command-line args. > > Are you getting the 'Firmware space is locked read-only' message then? yep... so let me ask a naive question... don't we want the firmware locked read-only because that protects the

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 13 Dec 2006, Chris Wright wrote: > * dean gaudet ([EMAIL PROTECTED]) wrote: > > just for the public record (i already communicated with Jan in private > > mail on this one)... i have a box which hangs hard starting at 2.6.18.2 > > and 2.6.19 -- hangs hard during t

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 29 Nov 2006, Jan Beulich wrote: > >>> Dave Jones <[EMAIL PROTECTED]> 24.11.06 21:27 >>> > >On Wed, Nov 22, 2006 at 08:53:08AM +0100, Jan Beulich wrote: > > > >It does appear to work w/out the patch. I've asked for a small bit > > > >of diagnostics (below), perhaps you've got something you

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: > On Mon, Dec 11, 2006 at 01:17:25PM -0800, dean gaudet wrote: > > rdtscp doesn't solve anything extra [..] > > [..] lsl-based vgetcpu is relatively slow > > Well, if you accept to run slow there's nothing to solve in th

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: > As far as I can see, many changes happened but nobody has yet added > the rdtscp support to x86-64. rdtscp finally solves the problem and it > obsoletes hpet for timekeeping and it allows a fully userland > gettimeofday running at maximum speed in use

RE: touch_cache() only touches two thirds

On Fri, 17 Nov 2006, dean gaudet wrote: > another pointer chase arranged to fill the L1 (or L2) using many many > pages. i.e. suppose i wanted to traverse 32KiB L1 with 64B cache lines > then i'd allocate 512 pages and put one line on each page (pages ordered > randomly), b

RE: touch_cache() only touches two thirds

On Fri, 10 Nov 2006, Bela Lubkin wrote: > The corrected code in > covers the full cache range. Granted that modern CPUs may be able to track > multiple simultaneous cache access streams: how many such streams are they > likely to be able to fol

Re: How to interpret MCE messages?

On Wed, 15 Nov 2006, martin f krafft wrote: > Thus I guess the CPU is asking for retirement. I am just > double-checking with you guys whether I can be sure that it's only > the CPU, or whether it could also be the fault of the motherboard... could be VRMs and/or PSU delivering unclean power... b

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

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: 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

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: 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: [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: [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: 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: [patch 1/2] fork_connector: add a fork connector

On Tue, 29 Mar 2005, Jay Lan wrote: > The fork_connector is not designed to solve accounting data collection > problem. > > The accounting data collection must be done via a hook from do_exit(). by the time do_exit() occurs the parent may have disappeared... you do need to record something at f

Re: [patch 1/2] fork_connector: add a fork connector

On Fri, 25 Mar 2005, Guillaume Thouvenin wrote: ... > The lmbench shows that the overhead (the construction and the sending > of the message) in the fork() routine is around 7%. ... > + /* > + * size of data is the number of characters > + * printed plus o

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: 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

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 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 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: 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: 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: 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: 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: [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: [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

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: 2.2.20pre2aa1

On Wed, 16 May 2001, Andrea Arcangeli wrote: > On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote: > > apache since 1.3.15 has defined SINGLE_LISTEN_UNSERIALIZED_ACCEPT ... > > That's definitely a good thing. hmm, i'm not so sure -- 1.3.x is our stable release

Re: 2.2.20pre2aa1

On Tue, 15 May 2001, Andrea Arcangeli wrote: > o fixed race in wake-one LIFO in accept(2). Apache must be compiled with > -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT to take advantage of that. > > 00_wake-one-4 > > Backport 2.4 waitqueues and in turn fixes an hanging condition in accept(2

Re: [Question] Explanation of zero-copy networking

On Mon, 7 May 2001, Richard B. Johnson wrote: > When we get to media that can sink data as fast as we can generate > them (it), then we have to worry about memory copy speed. However, > these new devices are actually an IP subsystem. They generate and > receive entire datagrams. To fully utilize

  1   2   >