On Wed, 10 Jan 2001, Alan Cox wrote:
it. I could never persuade Ingo to use wrmsr_eio() and check the
return code, maybe this will change his mind. Extract from kdb v1.7.
I have a patch from Ingo to fix this one properly. Its just getting tested
i prefer clear oopses and bug reports
On Thu, 11 Jan 2001, Frank Davis wrote:
Hello,
The following error occurred while compiling 2.4.0-ac6. [...]
vmalloc.c: In function `get_vm_area':
vmalloc.c:188: `PKMAP_BASE' undeclared (first use in this function)
you are compiling with HIGHMEM enabled (which makes sense only if you
On Thu, 11 Jan 2001, David Woodhouse wrote:
The bug here seems to be that we're using the same bit
(X86_FEATURE_APIC) to report two _different_ features.
i think that the AMD APIC is truly 'compatible', but we are trying to
enable the APIC and program performance counters in an Intel-way.
On Tue, 9 Jan 2001, David S. Miller wrote:
Nothing interesting or new, just merges up with the latest 2.4.1-pre1
patch from Linus.
ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz
I haven't had any reports from anyone, which must mean that it is
working perfectly
a new version against recent 2.4 kernels of my multimedia-lowlatency
patchset is now available. These patches are the 2.4-adapted versions of
my 2.2 lowlatency patch, which project has now reached an age of 1.5+
years.
the lowlatency patch against 2.4.0-ac6 can also be found at:
On Tue, 9 Jan 2001, Stephen Frost wrote:
Now, the interesting bit here is that the processes can grow to be
pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what
happens with MOSIX is that entire processes get sent over the wire to
other machines for work. MOSIX
On Thu, 11 Jan 2001, Christoph Lameter wrote:
I got into a bragging game whose webserver is the fastest with Jim
Nelson one of the authors of the boa webserver. We finally settled on
the Zeus test to decide the battle.
may i add my (hopefully comparable) TUX 2.0 numbers to this bragging
On Fri, 12 Jan 2001, Manfred Spraul wrote:
The PPro local apic documentation says:
The processor's local APIC includes an in-service entry and a holding
entry for each priority level. To avoid losing interrupts, software
should allocate no more than 2 interrupt vectors per priority.
On Fri, 12 Jan 2001, Manfred Spraul wrote:
2.4 spreads the vectors for the external (hardware, from io apic)
interrupts, but 5 ipi vectors have the same priority: reschedule, call
function, tlb invalidate, apic error, spurious interrupt.
my reading of the errata is that the lost APIC timer
On Fri, 12 Jan 2001, Linus Torvalds wrote:
[...] Ingo, what was the focus-cpu thing?
well, some time ago i had an ne2k card in an SMP system as well, and found
this very problem. Disabling/enabling focus-cpu appeared to make a
difference, but later on i made experiments that show that in both
On Fri, 12 Jan 2001, Frank de Lange wrote:
In addition, I patched apic.c (focus cpu enabled)
In addition, I patched io_apic ((TARGET_CPUS 0xff)
please try it with the focus CPU enabling change (we want to enable that
feature, i only disabled it due to the stuck-ne2k bug), but with
On Fri, 12 Jan 2001, Frank de Lange wrote:
WITH or WITHOUT the changed 8390 driver? I can already give you the
results for running WITH the changed driver: it works. I have not yet
tried it WITHOUT the changed 8390 driver (so that would be stock 8390,
patched apic.c, stock io_apic.c).
On Fri, 12 Jan 2001, Frank de Lange wrote:
BTW, does this (TARGET_CPUS cpu_online_mask) not wreak havoc with
systems with hot-pluggable CPUs (many Suns, etc...)? Wouldn;t it be
better to make this a config option (like the optional PCI fixes for
crappy BIOSs)?
? this is x86-only code.
On Fri, 12 Jan 2001, Frank de Lange wrote:
It is. As I already mentioned in other messages, I already tested with
JUST the patched 8390.c driver, no other patches. It was stable. I
then patched apic.c AND io_apic.c, which did not introduce new
instabilities. Unless you think that reverting
On Fri, 12 Jan 2001, Frank de Lange wrote:
PATCHED 8390.c (using irq_safe spinlocks instead of disable_irq)
PATCHED apic.c (focus cpu ENABLED)
STOCK io_apic.c
No problems under heavy network load.
Gentleman, this (the patch to 8390.c) seems to fix the problem.
great. Back when i had the
On Tue, 9 Jan 2001, David S. Miller wrote:
Is there any value to supporting fragments in a driver which
doesn't do hardware checksumming? IIRC Alexey had a patch to do
such for Tulip, but I don't see it in the above patchset.
I'm actually considering making the SG w/o hwcsum
On 13 Jan 2001 [EMAIL PROTECTED] wrote:
What is at http://www.kernel.org/pub/linux/kernel/people/mingo/
look official enough to me...
raid-2.2.18-B0 12-Jan-2001 10:18 392k
yep, it is the 'official' 2.2.18 RAID patch.
Ingo
-
To unsubscribe from this list: send the
On Sun, 14 Jan 2001, jamal wrote:
regular ttcp, no ZC and no sendfile. [...]
Throughput: ~99MB/sec (for those obsessed with Mbps ~810Mbps)
CPU abuse: server side 87% client side 22% [...]
sendfile server.
- throughput: 86MB/sec
- CPU: server 100%, client 17%
i believe what you are
On 14 Jan 2001, Linus Torvalds wrote:
Does anybody but apache actually use it?
There is a Samba patch as well that makes it sendfile() based. Various
other projects use it too (phttpd for example), some FTP servers i
believe, and khttpd and TUX.
Ingo
-
To unsubscribe from this list:
On Sun, 14 Jan 2001, Linus Torvalds wrote:
There is a Samba patch as well that makes it sendfile() based. Various
other projects use it too (phttpd for example), some FTP servers i
believe, and khttpd and TUX.
At least khttpd uses "do_generic_file_read()", not sendfile per se. I
assume
- the attached patch (against -ac9) fixes a bug in the RAID1 and RAID4/5
code that made raidhotremove fail under certain (rare) circumstances.
Please apply.
Ingo
--- linux/drivers/md/raid1.c.orig Mon Dec 11 22:19:35 2000
+++ linux/drivers/md/raid1.cMon Jan 15 14:45:35
On Mon, 15 Jan 2001, Jonathan Thackray wrote:
It's a very useful system call and makes file serving much more
scalable, and I'm glad that most Un*xes now have support for it
(Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to
Linux is sendpath(), which does the open()
()+sendfile()?
Ingo
--- linux/mm/filemap.c.orig Mon Jan 15 22:43:21 2001
+++ linux/mm/filemap.c Mon Jan 15 23:09:55 2001
@@ -39,6 +39,8 @@
* page-cache, 21.05.1999, Ingo Molnar [EMAIL PROTECTED]
*
* SMP-threaded pagemap-LRU 1999, Andrea Arcangeli [EMAIL PROTECTED
On 15 Jan 2001, Linus Torvalds wrote:
The performance problem is _probably_ due to the kernel having to
double-buffer the IO requests, coupled with bad MTRR settings (ie
memory above the 4GB range is probably marked as non-cacheable or
something, which means that you'll get really bad
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)
hey so how do you implement transmit timeouts with sendpath() ?
(i.e. drop the client after 30 seconds of no
On Mon, 15 Jan 2001, Linus Torvalds wrote:
_syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size)
You want to do a non-blocking send, so that you don't block on the
socket, and do some simple multiplexing in your server.
And "sendpath()" cannot do that without
On Tue, 16 Jan 2001, Andi Kleen wrote:
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can pass object
fingerprints and kernel pointers to other processes too
On Tue, 16 Jan 2001, Andi Kleen wrote:
the 'allocate first free file descriptor number' rule for normal Unix
files?
Not sure I follow. You mean dup2() ?
I'm sure you know this: when there are thousands of files open already,
much of the overhead of opening a new file comes from the
On Tue, 16 Jan 2001, Ingo Molnar wrote:
struct lazy_filedesc {
int fd;
struct file *file;
}
in fact "struct file" can (ab)used for this, no need for new structures or
new fields. Eg. file-f_flags contains the cached descriptor-informa
On Tue, 16 Jan 2001, Peter Samuelson wrote:
[Ingo Molnar]
- probably the most radical solution is what i suggested, to
completely avoid the unique-mapping of file structures to an integer
range, and use the address of the file structure (and some cookies)
as an identification
On Tue, 16 Jan 2001, Felix von Leitner wrote:
I don't know how Linux does it, but returning the first free file
descriptor can be implemented as O(1) operation.
only if special allocation patters are assumed. Otherwise it cannot be a
generic O(1) solution. The first-free rule adds an
On Tue, 16 Jan 2001, Felix von Leitner wrote:
I don't know how Linux does it, but returning the first free file
descriptor can be implemented as O(1) operation.
to put it more accurately: the requirement is to be able to open(), use
and close() an unlimited number of file descriptors with
On Wed, 17 Jan 2001, Micah Gorrell wrote:
I have a compaq 8 way server with 4 gigs of memory. I am running 2.4.0 and
everything works just fine (except the gig - I'm still fighting with that)
The only strange thing that I am seeing is that I only see 3.3 gigs of
memory instead of the full
On Wed, 17 Jan 2001, dean gaudet wrote:
with the linux TCP_CORK API you only get one trailing small packet.
in case you haven't heard of TCP_CORK -- when the cork is set, the
kernel is free to send any maximum size packets it can form, but has
to hold on to the stragglers until userland
On Wed, 17 Jan 2001, Rick Jones wrote:
i'd heard interesting generalities but no specifics. for instance,
when the send is small, does TCP wait exclusively for the app to
flush, or is there an "if all else fails" sort of timer running?
yes there is a per-socket timer for this. According to
On Wed, 17 Jan 2001, Linus Torvalds wrote:
(I also had one person point out that BSD's have the notion of
TCP_NOPUSH, which does almost what TCP_CORK does under Linux, except
it doesn't seem to have the notion of uncorking - you can turn NOPUSH
off, but apparently it doesn't affect queued
On Wed, 17 Jan 2001, Rick Jones wrote:
certainly, i see by your examples how cork can make life easier on the
developer - they can putc() the reply if they want. for a persistent
http connection, there would be the cork and uncork each time, for a
pipelined connection, it is basically a
On Thu, 18 Jan 2001, Linus Torvalds wrote:
Yeah, and how are you going to teach a perl CGI script that writes to
stdout to use it?
yep, correct. But you can have TCP_CORK behavior from user-space (by
setting the cork flag in user-space and writing it for all network
output), while you cannot
On Thu, 18 Jan 2001, Linus Torvalds wrote:
Remember the UNIX philosophy: everything is a file. MSG_MORE
completely breaks that, because the only way to use it is with
send[msg](). It's absolutely unusable with something like a
traditional UNIX "anonymous" application that doesn't know or
On Thu, 18 Jan 2001 [EMAIL PROTECTED] wrote:
Actually, TUX-1.1 (Ingo, do I not lie, did you not kill this code?)
does this. It does not ack quickly, when complete request is received
and still not answered, so that all the redundant acks disappear.
(it's TUX 2.0 meanwhile), and yes, TUX
On Thu, 18 Jan 2001, Linus Torvalds wrote:
I think Andrea was thinking more of the case of the anonymous IO
generator, and having the "controller" program thgat keeps the socket
always in CORK mode, but uses SIOCPUSH when it doesn't know what teh
future access patterns will be.
yep.
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
{
int val = 1;
setsockopt(req-sock, IPPROTO_TCP, TCP_CORK,
(char *)val,sizeof(val));
val = 0;
setsockopt(req-sock, IPPROTO_TCP, TCP_CORK,
(char *)val,sizeof(val));
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
This is a possible slow (but userspace based) implementation of SIOCPUSH:
of course this is what i meant. Lets stop wasting time on this, ok?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
BTW, the simmetry between getsockopt/setsockopt further bias how
SIOCPUSH doesn't fit into the setsockopt options but it fits very well
into the ioctl categorty instead. There's simply no state one can
return via getsockopt for the SIOCPUSH
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
Agreed. However since TCP_CORK logic is more generic than MSG_MORE
[...]
why? TCP_CORK is equivalent to MSG_MORE, it's just a different
representation of the same issue. TCP_CORK needs an extra syscall (in the
case of a push event - which might be
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
I'm all for TCP_CORK but it has the disavantage of two syscalls for
doing the flush of the outgoing queue to the network. And one of those
two syscalls is spurious. [...]
i believe a network-conscious application should use MSG_MORE - that has
no
On Sun, 21 Jan 2001, James Sutherland wrote:
For many applications, yes - but think about a file server for a
moment. 99% of the data read from the RAID (or whatever) is really
aimed at the appropriate NIC - going via main memory would just slow
things down.
patently wrong. Compare the
the attached patch (against -pre9) fixes a possibly dangerous sys_wait4()
prototype mismatch.
Ingo
--- linux/include/linux/sched.h.origMon Jan 22 17:28:36 2001
+++ linux/include/linux/sched.h Mon Jan 22 17:29:17 2001
@@ -563,6 +563,7 @@
#define wake_up_interruptible_all(x)
a new, 'ultra SMP scalable' implementation of Linux kernel timers is now
available for download:
http://www.redhat.com/~mingo/scalable-timers/smptimers-2.4.0-B1
the patch is against 2.4.1-pre10 or ac12. The timer design in this
implementation is a work of David Miller, Alexey Kuznetsov and
On Tue, 30 Jan 2001, Neil Brown wrote:
-#define MAX_MD_BOOT_DEVS 8
+#define MAX_MD_BOOT_DEVS MAX_MD_DEVS
Actually, this is not fine. Check the code that says:
indeed - it will work only up to 32 devices.
i've fixed the code to not have this assumption - it's init-time code only
On Mon, 29 Jan 2001, Quim K Holland wrote:
I've been following the recent 2.4.1-pre series and am wondering why
the following one-liner (obviously correct) patch has not been
applied. [...]
- return_ok = bh-b_reqnext;
+ return_fail = bh-b_reqnext;
oops - i do
On Tue, 30 Jan 2001, jamal wrote:
Kernel | tput | sender-CPU | receiver-CPU |
-
2.4.0-pre3 | 99MB/s | 87% | 23% |
NSF||| |
-
On Tue, 30 Jan 2001, jamal wrote:
- is this UDP or TCP based? (UDP i guess)
TCP
well then i'd suggest to do:
echo 10 10 10 /proc/sys/net/ipv4/tcp_wmem
does this make any difference?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, 31 Jan 2001, Malcolm Beattie wrote:
Without the raised tcp_wmem setting I was getting 81 MByte/s. With
tcp_wmem set as above I got 86 MByte/s. Nice increase. Any other
setting I can tweak apart from {r,w}mem_max and tcp_{w,r}mem? The CPU
on the client (350 MHz PII) is the
On Sun, 20 May 2001, Dave Airlie wrote:
I'm implementing start_thread for the VAX port and am wondering does
start_thread have to return to load_elf_binary? I'm working on the
init thread and what is happening is it is returning the whole way
back to the execve caller .. which I know
On Sat, 19 May 2001, Jacob Luna Lundberg wrote:
This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in.
Unable to handle kernel paging request at virtual address 78626970
this appears to be some sort of DMA-corruption or other memory scribble
problem. hexa 78626970 is ASCII pibx,
On Sun, 20 May 2001, Jacob Luna Lundberg wrote:
Unable to handle kernel paging request at virtual address 78626970
this appears to be some sort of DMA-corruption or other memory scribble
problem. hexa 78626970 is ASCII pibx, which shows in the direction of
some sort of disk-related DMA
On Sat, 26 May 2001, Andrea Arcangeli wrote:
On Sat, May 26, 2001 at 02:11:15PM -0400, Ben LaHaise wrote:
No. It does not fix the deadlock. Neither does the patch you posted.
can you give a try if you can deadlock 2.4.5aa1 just in case, and post a
SYSRQ+T + system.map if it still
i've been seeing really bad average TCP latencies on certain gigabit cards
(~300-400 microseconds instead of the expected 100-200 microseconds), ever
since softnet went into the main kernel, and never found a real
explanation for it, until today.
the problem always went away when i tried to use
On Sun, 20 May 2001, Alexander Viro wrote:
Linus, as much as I'd like to agree with you, you are hopeless
optimist. 90% of drivers contain code written by stupid gits.
90% of drivers contain code written by people who do driver development in
their spare time, with limited resources, most of
On Sun, 27 May 2001, David S. Miller wrote:
Hooray, some sanity in this thread finally :-)
[ finally i had some sleep after a really long debugging session :-| ]
the attached softirq-2.4.5-B0 patch fixes this problem by calling
do_softirq() from local_bh_enable() [if the bh count is
On Sun, 27 May 2001, Andrea Arcangeli wrote:
Yes the stock kernel.
yep you are right.
i had this fixed too at a certain point, there is one subtle issue: under
certain circumstances tasklets re-activate the tasklet softirq(s) from
within the softirq handler, which leads to infinite loops if
the attached ioapic-2.4.5-A1 patch includes a number of important IO-APIC
related fixes (against 2.4.5-ac3):
- correctly handle bridged devices that are not listed in the mptable
directly. This fixes eg. dual-port eepro100 devices on Compaq boxes
with such PCI layout:
-+-[0d]---0b.0
the attached patch (against 2.4.5-ac3) fixes a compiler warning (triggered
by gcc 2.96) in the RAID include files.
Ingo
--- linux/include/linux/raid/md_k.h.origTue May 29 12:50:30 2001
+++ linux/include/linux/raid/md_k.h Tue May 29 12:50:40 2001
@@ -38,6 +38,7 @@
the attached softirq-2.4.5-E5 patch (against 2.4.5-ac3) tries to solve all
softirq, tasklet and scheduling latency problems i could identify while
testing TCP latencies over gigabit connections. The list of problems, as
of 2.4.5-ac3:
- the need_resched check in the arch/i386/kernel/entry.S
On Tue, 29 May 2001, Hilik Stein wrote:
I am running a Linux machine with a 1GB Ethernet card which takes a
huge amount of packets, which results in many HW interrupts. is it
possible to make sure that only CPU #1 handles all the hardware
interrupts generated by the NIC ? or even all the
On Tue, 29 May 2001, Jaswinder Singh wrote:
What is the nice way (in accuracy and performance) to emulate RDTSC in
Linux for those architectures who dont support RDTSC like in Hitachi
SH Processors.
if the hardware provides no way to get some accurate estimation of current
time, then there
By making this (logical, and needed) feature unconditional, your patch's
size and complexity is reduced by 80%. (see the attached
pc_speaker.patch2)
Ingo
diff -u --recursive linux-2.4.5/drivers/char/vt.c linux-2.4.5-nc/drivers/char/vt.c
--- linux-2.4.5/drivers/char/vt.c Fri
less code / one int more in the kernel
or
more code and #ifs / one int less in the kernel
if the #ifdefs bloat the code 4 times the size of the simple patch, then
we obviously want 4 bytes more in the kernel.
And what about the code from kernel/sys.c ? The version you provided
doesn't
On Wed, 30 May 2001 [EMAIL PROTECTED] wrote:
I use the 'pgt_offset', 'pmd_offset', 'pte_offset' and 'pte_page'
inside a module to get the physical address of a user space virtual
address. The physical address returned by 'pte_page' is not page
aligned whereas the virtual address was page
On Wed, 30 May 2001, Nico Schottelius wrote:
the default value is 0, that is good enough.
hmm.. I don't think so... value of 1 would be much better, because
0 normally disables the speaker.
i confused the value. Yes, an initialization to 1 would be the correct,
ie.:
+++
On Wed, 30 May 2001, Pete Wyckoff wrote:
__pa(page_address(pte_page(pte))) is the address you want. [or
pte_val(*pte) (PAGE_SIZE-1) on x86 but this is platform-dependent.]
Does this work on x86 non-kmapped highmem user pages too? (i.e. is
page-virtual valid for every potential user
On Sun, 27 May 2001, Andrea Arcangeli wrote:
I mean everything is fine until the same softirq is marked active
again under do_softirq, in such case neither the do_softirq in do_IRQ
will run it (because we are in the critical section and we hold the
per-cpu locks), nor we will run it again
On Tue, 29 May 2001, Dawson Engler wrote:
Believe it or not, this one is OK :-)
All callers pass in a pointer to a local stack kernel variable
in raddr.
Ah. I assumed that sys_* meant that all pointers were from user
space --- is this generally not the case? (Also, are there other
On Thu, 31 Aug 2000, Alan Cox wrote:
We then just follow the bios. You can also reserve blocks of memory by
hacking arch/i386/mm/init.c and marking them reserved
in 2.4 there is an explicit interface for this that also guarantees that
the allocation consists of fully valid RAM (no matter how
We are pleased to announce that the TUX kernel-space HTTP-subsystem is
available for download at:
ftp://ftp.redhat.com/pub/redhat/tux/tux-hawaii/
WARNING: this is a developer-only, alpha release. The 1.0 'consumer'
release will happen by the end of September. This release is useless to
On Sat, 2 Sep 2000, Alexander Viro wrote:
Why? I would say that bad thing about SysV shared memory is that it's
_not_ sufficiently filesystem-thing - a special API where 'create a
file on ramfs and bloody mmap() it' would be sufficient. Why bother
with special sets of syscalls?
what i mean
On 2 Sep 2000, Jes Sorensen wrote:
You can't DMA directly from a file cache page unless you have a
network card that does scatter/gather DMA and surprise surprise,
80-90% of the cards on the market don't support this. [...]
exactly. The TUX patch solves this by copying 'multi-fragment skbs'
On Sat, 2 Sep 2000, Jeff V. Merkey wrote:
**ALL** Netware network drivers support a scatter/gather proramming
interface, whether the hardware does or not. In NetWare, the drivers
get passed a fragment list in what's called an ECB (Event Control
Block). It's the drivers responsiblity to
On Sun, 3 Sep 2000 [EMAIL PROTECTED] wrote:
If we go for a Linux-specific solution anyway, maybe one could add
another send{,to,msg} flag that makes send*(2)'s buffer access
non-atomic. That way, the kernel only needs to make sure the pages
don't disappear, but there's no need for expensive
On Sun, 3 Sep 2000, Andi Kleen wrote:
I did the same for fragment RX some months ago (simple fragment lists
that were copy-checksummed to user space). Overall it is probably
better to use a kiovec, because that can be more easily used in nfsd
and sendfile.
the basic fragment type
On Sun, 3 Sep 2000, Andi Kleen wrote:
You can already cause incorrect checksums on the wire just by passing
a partly unmapped address (the zero-the-rest exception handler in
csum_copy_generic in i386 forgets to add in the carry)
I do not believe it is a big deal, packets with bad checksum
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
while (x)
{
x = x-next
}
all over the place that increases latency. [...]
i challenge you to show one such place in the 2.4.0-test8-pre2 kernel. If
it's all over the place and if it increases latency, you certainly can
show
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
Alright Ingo, you asked for it. I am going through it now and going
over ALL my notes. I will catalog ALL of them and post it. Is this
what you really want?
yes, this would be the best indeed, to get those places fixed. But if you
dont want to spend
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
The origin of this comment was related to a comparison of the
MSM/TSM/CSM layer in NetWare and Linux. I've already said that Alan's
code handles fast paths well and from what I've seen is comparable to
NetWare. [...]
can we thus take this as a
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
[...] The point is that a write() is only used if some sort of
dynamic data is generated on the fly.
There are exsiting applications out there that use mmap+write
(caching the maps), it would be nice for the authors of these not to
have
On Wed, 6 Sep 2000, Frank Peters wrote:
My question is who cleared it the kernel or the malloc function in
glibc?? (i found some code in glibc but nothing in kernel) thx
it's the second clear_user_highpage() in mm/memory.c that does the page
clearing in the typical malloc()-ed memory case.
On Wed, 6 Sep 2000, J. Dow wrote:
If the Kernel Debugger creates faulty solutions through lack of
thinking, and asking why, then surely printk is at least as bad
because it allows somebody to view the operation of the kernel through
a keyhole darkly. [...]
i'd like to quote David here,
On Tue, 5 Sep 2000, Alan Cox wrote:
I spend my time thinking. But I prefer to spend it thinking about the
bug not about finding it and how long fsck takes. [...]
if we only optimize for the debugging time spent by seasoned kernel
developers then you are completely right. But if we optimize
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
Your arguments are personal, not technical. [...]
no, my arguments are technical, but are simply focused towards the
conceptual (horizontal) development of Linux, not the vertical
development of Linux (drivers) and support issues.
Ingo
-
To
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
A kernel debugger will reduce development costs. [...]
... of Jeff V. Merkey - possibly. You are too much focused on your own
needs, you dont contribute a bit to the generic kernel and the kernel
infrastructure itself.
Ingo
-
To unsubscribe
i'm seeing similar problems. I think these problems started when the
elevator was rewritten, i believe it broke the proper unplugging of IO
devices. Does your performance problem get fixed by the attached
workaround?
Ingo
On Thu, 14 Sep 2000, Robert Cohen wrote:
For a while, Ive been
i strongly disagree. It's a nightmare to have three variants of the same
code at once. (mdtools, raidtools and raidtools2.) This mess has been
cleaned up in 2.4, and we shouldnt touch 2.2's RAID code beyond bugfixes.
This is not support for 'old hardware', it's support for the very same
thing.
i'm wondering about the following piece of code in refill_inactive():
if (current-need_resched (gfp_mask __GFP_IO)) {
__set_current_state(TASK_RUNNING);
schedule();
}
shouldnt this be __GFP_WAIT? It's true that
i've seen a couple of GFP_BUFFER allocation deadlocks in an atypical
system which had lots of RAM allocated to inodes. The reason for the
deadlock is that the shrink_*() functions cannot be called if __GFP_IO is
not set. Nothing else can be freed at that point, so the try_again: loop
in
On Sun, 24 Sep 2000, Linus Torvalds wrote:
[...] I don't think shrinking the inode cache is actually illegal when
GPF_IO isn't set. In fact, it's probably only the buffer cache itself
that has to avoid recursion - the other stuff doesn't actually do any
IO.
i just found this out by
the attached vmfixes-B2 patch adds the following fixes/cleanups:
vmscan.c:
- check for __GFP_WAIT not __GFP_IO when yielding the CPU. This fixes
GFP_BUFFER deadlocks. In fact since no caller to do_try_to_free_pages()
can expect that function to not block, we dont test for __GFP_WAIT
On Sun, 24 Sep 2000, Andrea Arcangeli wrote:
ext2_new_block (or whatever that runs getblk with the superlock lock
acquired)-getblk-GFP-shrink_dcache_memory-prune_dcache-
prune_one_dentry-dput-dentry_iput-iput-inode-i_sb-s_op-
put_inode-ext2_discard_prealloc-ext2_free_blocks-lock_super-D
On Mon, 25 Sep 2000, Mark Hahn wrote:
The problem is large numbers of threads in 2.4.0-test8 can result in a
hard crash of the entire kernel. This can be done as a non-root user.
this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
i've done some experimentation,
indeed, after changing max_queued_signals to 4096, i cannot crash the
kernel anymore with 2000 threads.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
1 - 100 of 32618 matches
Mail list logo
