Marting Mokreja wrote:
> first of all, sorry for not being up to date with how the OOM killer
> works. I think there used to be a kernel config option to disable
> OOM killer and instead kill the process which actually asks for the
> memory and supposedly caused the memory lack. That is what I woul
On Nov 29, 2007 7:37 AM, Xavier Bestel <[EMAIL PROTECTED]> wrote:
> > One sticking point is that apps like Photoshop and probably
> > Punkbuster want to retrieve the hard drive's serial number
>
> So they can't be installed on a network drive ?
I think Adobe supports that, though perhaps not with
On 2000-09-07, in
http://marc.info/?l=linux-kernel&m=96836765403118&w=2, Linus wrote:
> Hmm.. I have this feeling that it would be much nicer to
> just implement the NT system calls directly.
> ...
> I wouldn't be adverse to supporting Wine better...
A few years on, Wine has matured to the point w
On 7/6/07, Jeff Dike <[EMAIL PROTECTED]> wrote:
UML is cloning a thread in order to test the host's ptrace. However,
it looks like valgrind is branching to 0x9 for some reason.
This particular bit is going to be problematic for other reasons, but
if valgrind ever looks like it has a chance of w
It'd be nice to see if Valgrind could catch uninitialized
references in the kernel, if only to see if Coverity is
missing anything that happens in practice.
Back in December 2002, Valgrind started to run UML:
http://user-mode-linux.sourceforge.net/diary.html
http://marc.info/?l=linux-kernel&m=104
George Van Tuyl <[EMAIL PROTECTED]> wrote:
> gcc: Internal error: Segmentation fault (program cpp0)
> ...
> make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan'
> ...
> Gnu C 2.96
> ...
cpu family: 6
model : 4
model name: AMD Athlon(tm) Processor
ste
Dan Kegel wrote:
I've been doing builds of linux-2.6.11 as a sanity check
for new versions of gcc, and a problem just popped up
in arch/alpha/Makefile (see
http://gcc.gnu.org/ml/gcc/2005-07/msg00397.html)
Never mind. rth kindly explained to me that
it's a gcc or binutils problem.
I've been doing builds of linux-2.6.11 as a sanity check
for new versions of gcc, and a problem just popped up
in arch/alpha/Makefile (see http://gcc.gnu.org/ml/gcc/2005-07/msg00397.html)
I think I can work around this myself by using CONFIG_ALPHA_EV6
instead of CONFIG_ALPHA_GENERIC, but here's my
Arjan van de Ven wrote:
hmm. I wonder if a slightly different approach (based on the __slow)
idea would make sense
1) Use -ffunction-sections option from gcc to put each function in it's
own section
2) Use readprofile/oprofile data to collect an (external to the code)
list of hot/cold functions (
Andrew Morton wrote:
LTP-20050405
It seems to have an x86ism in it which causes the compile to fail on ppc64:
socketcall01.c: In function `socketcall':
socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with
asm clobber list
That might be a problem with your toolchain.
Other m
Andrew Morton wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used uninitialized
in this function
make[
Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used uninitialized
in this function
make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
make: *** [arch/alpha/kernel] Error 2
I g
gcc-4.0 fails with
"error: array type has incomplete element type"
(see http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html)
on several files in linux-2.6.11.3.
Who knows, maybe all this is fixed in the -mm tree already,
but what the heck, here are a few fixes I haven't seen anyone
else post yet. Thes
Dan Kegel wrote:
> Pseudocode:
>
> sigemptyset(&s);
> sigaddset(SIGUSR1, &s);
> fd=sigopen(&s);
> m=read(fd, buf, n*sizeof(siginfo_t))
> close(fd);
>
> should probably be equivalent to
>
> sigemptyset(&s);
> sigaddset(SIG
Chriss wrote:
> I wrote a simple server application and installed it on a linux machine
> in Slovakia, running Mandrake 7.2 (2.2.18).
> That machine loses tcp/ip packages, as it uses a Microwave connection.
> So my server works all the time, and the tcp/ip connections are set to
> TIME_WAIT, but a
Alan Cox wrote:
>
> > the boss say "If Linux makes Sybase go through the page cache on
> > reads, maybe we'll just have to switch to Solaris. That's
> > a serious performance problem."
>
> Thats something you'd have to benchmark. It depends on a very large number
> of factors including whether
At work I had to sit through a meeting where I heard
the boss say "If Linux makes Sybase go through the page cache on
reads, maybe we'll just have to switch to Solaris. That's
a serious performance problem."
All I could say was "I expect Linux will support O_DIRECT
soon, and Sybase will support t
Christopher Smith wrote:
>
> At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >From: Christopher Smith <[EMAIL PROTECTED]>
> > >I guess the main thing I'm thinking is this could require some significant
> > >changes to the way the kernel behaves. Still, it's worth taking a "try it
> > >and s
Christopher Smith wrote:
>
> At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >Balbir Singh <[EMAIL PROTECTED]> wrote:
> > >sigopen() should be selective about the signals it allows
> > >as argument. Try and make sigopen() thread specific, so that if one
> > >thread does a sigopen(), it does
Once upon a time a hacker named Xman
wrote a library that used aio, and decided
to use sigtimedwait() to pick up completion
notifications. It worked well, and his I/O
was blazing fast (since was using a copy
of Linux that was patched to have good aio).
But when he tried to integrate his library
i
Russell Leighton wrote:
> The lack of a good operating system _dependent_ interface
> makes running fast hard in Java when you need to do IO...
> yes, there is always JNI so you can add a little C to mmap a file or whatever,
JDK 1.4 beta comes with a way to memory-map files, and various
other I/O
[EMAIL PROTECTED] wrote:
>
> On an unrelated note:
>
> I noticed the quote below in your message. Is this a true quote or just a
> joke going around? I have tried believing it is just a joke but I am
> scared it is not.
>
> >--
> > "A Computer is a state machine.
> > Threads are for people who
"J . A . Magallon" wrote:
> I have just the same problem. getrusage() did not catch the CPU time for
> children, even if the man page said that. Now I am using times(2), that
> seems to work in Solaris, but gives nothing in Linux.
>
> I you look at time(1) manpage, it says time is implemented ove
Pete Wyckoff wrote:
>
> [EMAIL PROTECTED] said:
> > I'd like to monitor CPU, memory, and I/O utilization in a
> > long-running multithreaded daemon under kernels 2.2, 2.4,
> > and possibly also Solaris (#ifdefs are ok).
>
> getrusage() isn't really the system call you want for this.
I'll buy th
I'd like to monitor CPU, memory, and I/O utilization in a
long-running multithreaded daemon under kernels 2.2, 2.4,
and possibly also Solaris (#ifdefs are ok).
getrusage() looked promising, and might even work for CPU utilization.
Dunno if it returns info for all child threads yet, haven't tried
Pierre Phaneuf <[EMAIL PROTECTED]> wrote:
> It's fairly widely-known that select/poll returns immediately when
> testing a filesystem-based file descriptor for writability or
> readability.
>
> On top of this, even when in non-blocking mode, read() could block if
> the pages needed aren't in core
Sean Hunter wrote:
> On Sat, May 19, 2001 at 10:31:01AM +0200, Sasi Peter wrote:
> > On Fri, 18 May 2001, Sean Hunter wrote:
> >
> > > Why would you want to run a web server with 8 processors rather than four
> > > webservers with 2 each?
> >
> > As you might already know, after the intervie
Sasi Peter <[EMAIL PROTECTED]> wrote:
> I am just writing an essay, an have mentioned TUX as a performance and
> scalability linearity recort holder with TUX, referencing the specweb99
> website summary page:
>
> http://www.spec.org/osg/web99/results/web99.html
>
> However, taking a closer l
Tomas Telensky ([EMAIL PROTECTED]) wrote:
> does anybody know about any archive/digest service for this mailing
> list? Majordomo at vger doesn't support this. Or does anybody of you
> archive all e-mails?
>
> I'm especially interested in the _WHOLE_ thread "No 100Hz timer !" now.
> (but the
Stefan Hoffmeister wrote:
> >Since there is no kgcc in RH71,
>
> There is an compat-egcs RPM (on CD2?) that contains kgcc. Took me a while
> to find that.
OH. I kept looking for a package called 'kgcc'. Silly me.
Guess it's time for a "How to compile a kernel on Red Hat 7.1" FAQ.
- Dan
-
To u
Federico Edelman Anaya ([EMAIL PROTECTED]) wrote:
> What can I do to test the FD limit? ... Because, the FD limit is set in
> /proc/sys/fs/file-max, sample:
>
> echo "2048" > /proc/sys/fs/file-max
That sets the systemwide limit to 2048.
> ulimit -n 8192
That sets the per-process limit (
[EMAIL PROTECTED] wrote:
> I want to contact with the author of linux kernel.
> Anybody knows how to contact with them?
> Our leader hope put our own driver into linux kernel. I am not sure whether
> it was permitted.
> So, I need to contact with the authors of linux kernel.
> If you know how
Tony Hoyle ([EMAIL PROTECTED]) wrote:
> Is there a way that gdb/ddd could be invoked when a program is about
> to dump core...?
Yes, I use that to get a symbolic stack dump after a crash,
although I find that the gdb so invoked doesn't accept interactive
commands, and I have to use 'kill -9' af
> How can I increase the FD in the Kernel 2.4.3?
echo 32768 > /proc/sys/fs/file-max
See also http://www.kegel.com/c10k.html#limits.filehandles
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
Mark Hahn wrote:
> the main goal at this point is to make kernel proc-related
> code more efficient, easy-to-use, etc. a purely secondary goal
> is to make user-space tools more robust, efficient, and simpler.
>
> there are three things that need to be communicated through the proc
> interfac
Jesse Pollard wrote:
> > But one thing XML provides (potentially) is a DTD that defines meanings and
>formats.
> > IMHO the kernel needs something like this for /proc (though not in DTD format!).
> >
> > Has anyone ever tried to write a formal syntax for all the entries
> > in /proc? We have bi
Jesse Pollard wrote:
> Personally, I think
> proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild);
> (or the string " ddd" with d representing a digit)
>
> is shorter (and faster) to parse with
> fscanf(input,"%d %d",&usbdev,&maxchild);
>
> Than it would be to
Tim Jansen wrote:
>
> On Wednesday 25 April 2001 19:10, you wrote:
> > The command
> > more foo/* foo/*/*
> > will display the values in the foo subtree nicely, I think.
>
> Unfortunately it displays only the values. Dumping numbers and strings
> without knowing their meaning (and probably not
Tim Jansen wrote:
> On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
> >> Are there alternatives to get complex and extendable information out to
> >> user space?
> > Yes filesystem structures.
>
> How exactly can this work? A single value per file is not very helpful if you
> have a th
Dear Sistina:
I know very little about LVM, but from watching earlier projects
in the same situation you're in now, the path you need to follow
seems clear:
Stop using CVS internally for development.
It makes checking in changes without submitting them to
Linus too easy.
To get sync'd
jdow wrote:
> Miles, if these babies are the 32 processor monsters that UniSys
> has been making recently there IS interest to get Linux on it.
> But the people I know who have mentioned "interest", mostly from
> a curiosity standpoint, have their hands neatly tied by Microsoft.
> Ya see, the
[EMAIL PROTECTED] wrote:
> I have been trying to differenciate threads and process in Linux. As
> I am sure you already know, other OS, namely HPUX, implement threads
> in a different way. ...
> Of course, I am talking about kernel 2.2.x, but AFAIK this has not
> changed in the new kernels.
It
[EMAIL PROTECTED] asked:
> hey, I hear that wine ( windows emulator ) can port into kernel and make
> it running faster, How can I do it?
> or anyone can make a patch to add wine code into kernel?
> waiting for answer, Thanks
It's not ready for prime time yet.
There is some discussion of the
Alexy wrote:
> > > How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
>
> They have not so much of common.
>
> TCP_NOPUSH enables T/TCP and its presense used to mean that
> T/TCP is possible on this system. Linux headers cannot
> even contain TCP_NOPUSH.
But Tony Finch wrote:
Alan Cox wrote:
>
> > How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
> > If it does behave identically, it might be time to standardize
> > the symbolic name for this option, to make apps more portable
> > between the two OS's. (It'd be nice to also standardize the
> > numeric
Tony Finch wrote:
>
> Tony Finch <[EMAIL PROTECTED]> wrote:
> >Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >>
> >>Without proper uncorking (and it really shouldn't be that hard to
> >>add), TCP_NOPUSH simply can't be used in the generic sense.
> >
> >It was easy :-) I've put up a patch for FreeBS
Mathieu Dube wrote:
> when accept return -1 perror gives me "No buffer space available"
> What do you think that means??
Better ask a real net guru :-)
Or look at the sources.
in /usr/src/linux/net/ipv4/af_inet.c
int inet_create() {
...
sk = sk_alloc(PF_INET, GFP_KERNEL, 1);
sct wrote:
> On Wed, Jan 31, 2001 at 04:12:11PM +0530, [EMAIL PROTECTED] wrote:
> >
> > Thanks for mentioning this. I didn't know about it earlier. I've been
> > going through the 4/00 kqueue patch on freebsd ...
>
> Linus has already denounced them as massively over-engineered...
That sho
Mohit Aron wrote:
>
> > http://opensource.corel.com/cprof.html
> >
> > I haven't used it yet, myself.
> >
>
> I have. cprof is no good - extremely slow and generates a 100MB trace
> even with a simple hello world program.
Oh. Bleh.
http://wordindex.sourceforge.net/testdata/usenet.col-2817
See
http://opensource.corel.com/cprof.html
I haven't used it yet, myself.
- Dan
-
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/
Dean Gaudet wrote:
> consider the case where you're responding to a pair of pipelined HTTP/1.1
> requests. with the HPUX and BSD sendfile() APIs you end up forcing a
> packet boundary between the two responses. this is likely to result in
> one small packet on the wire after each response.
>
Albert D. Cahalan ([EMAIL PROTECTED]) wrote:
> Christoph Rohland writes:
> > I am quite open about naming, but "shm" is not appropriate any more
> > since the fs does a lot more than shared memory. Solaris calles this
> > "tmpfs" but I did not want to 'steal' their name and I also do not
> > t
Michael Rothwell ([EMAIL PROTECTED]) wrote:
> How about using fcntl(), O_ASYNC and SIGIO?
Don't think that's supported for disk files yet, at least by the
kernel. glibc does aio emulation with threads, which isn't great.
> Or maybe a broader question:
> what's the preferred/working way to do
Micah wrote:
> I have been trying to increase the scalabilty of
> an email server that has been ported to Linux. It
> was originally written for Netware, and there we
> are able to provide over 30,000 connections at any
> given time. On Linux however select stops working
> after the first 1024 con
Michael D. Crawford ([EMAIL PROTECTED]) asked:
> Can you tell me about any ready-to-use test suites,
> for any software package that should run under Linux,
> that I can build and run to test the new kernel?
The LSB has a set of test suites it has gathered for Linux itself;
see http://www.linu
Manfred wrote:
> The improvement with large number of pipes probably comes from replacing
> __get_free_page() with kmalloc() - kmalloc is faster, especially on SMP.
> ...
> I expected 2 improvements:
> * poll with < 24 descriptors: around 800 cpu ticks faster, but that's
> just one or two microsec
Manfred ([EMAIL PROTECTED]) wrote:
> sys_poll spends around 1/2 of the execution time allocating / freeing a
> few bytes temporary memory.
> The attached patch tries to avoid these allocation by using the stack -
> usually only a few bytes are needed, kmalloc is used for the rest.
> The result
Dan Kegel wrote:
> Daniel Walton ([EMAIL PROTECTED]) wrote:
> > I've been having a problem with a high volume Linux web server. This
> > particular web server used to be a FreeBSD machine and I've been trying to
> > successfully make the switch for some tim
Daniel Walton ([EMAIL PROTECTED]) wrote:
> I've been having a problem with a high volume Linux web server. This
> particular web server used to be a FreeBSD machine and I've been trying to
> successfully make the switch for some time now. I've been trying the 2.4
> development kernels as they c
[EMAIL PROTECTED] asked:
> [Why does this program not crash?]
>
> main()
> {
>char *s;
>s = (char*)malloc(0);
>strcpy(s,"f");
>printf("%s\n",s);
> }
It doesn't crash because the standard malloc is
optimized for speed, not for finding bugs.
Try linking it with a debuggi
Lyle asked:
> Is someone working on Linus's poll variation discussed in this list a week ago?
I think the interface still needs some discussion.
The interface Linus proposed is IMHO oriented towards ease of
kernel implementation, and doesn't appear to be easy to use
for all applications.
cf. re
Mike Jagdis wrote:
> This patch firstly extends the wait queue mechanism
> to allow an arbitrary action to be performed. Then I rewrote
> the select/poll implementation to use event queueing to avoid
> rescanning descriptors that had not changed - and restructured
> the loops to be rather more eff
John Gardiner Myers wrote:
>
> Dan Kegel wrote:
> > IMHO you're describing a situation where a 'completion notification event'
> > (as with aio) would be more appropriate than a 'readiness notification event'
> > (as with poll).
>
>
John Gardiner Myers <[EMAIL PROTECTED]> wrote:
> Your proposed interface suffers from most of the same problems as the
> other Unix event interfaces I've seen. Key among the problems are
> inherent race conditions when the interface is used by multithreaded
> applications.
>
> The "stickiness
> >In fact, if you did leave the read queued in a daemon using select()
> >before, you'd keep looping endlessly taking all CPU and never idle
> >because there would always be read data available.
That would be a programming error on the part of the application.
Any application using a level-tr
Terry Lambert wrote:
>
> > > Which is precisely why you need to know where in the chain of events this
> > > happened. Otherwise if I see
> > > 'read on fd 5'
> > > 'read on fd 5'
> > > How do I know which read is for which fd in the multithreaded case
> >
> > That can't happen, c
Alan Cox wrote:
> > > kqueue currently does this; a close() on an fd will remove any pending
> > > events from the queues that they are on which correspond to that fd.
> >
> > the application of a close event. What can I say, "the fd formerly known
> > as X" is now gone? It would be incorrect t
Linus Torvalds wrote:
> However, we also need to remember what got us to this discussion in the
> first place. One of the reasons why poll() is such a piggy interface is
> exactly because it tries to be "nice" to the programmer.
poll() is a piggy interface because it is O(n) in polled file
descr
Jim Gettys wrote:
> So I want an interface in which I can get as many events as possible
> at once, and one in which the events themselves can have appropriate
> aggregation behavior. It isn't quite clear to me if the proposed interface
> would have this property.
I believe get_event, /dev/poll,
"Eric W. Biederman" wrote:
>
> Dan Kegel <[EMAIL PROTECTED]> writes:
> > It's harder to write correct programs that use edge-triggered events.
>
> Huh? The race between when an event is reported, and when you take action
> on it effectively means all e
Helge Hafting wrote:
> > With poll(), it was *not a bug* for the user code to drop events; with
> > your proposed interface, it *is a bug* for the user code to drop events.
> > I'm just emphasizing this because Simon Kirby ([EMAIL PROTECTED]) posted
> > incorrectly that your interface "has the sam
Johnathan,
Thanks for running that test for me! I've added your results
(plus a cautionary note about microbenchmarks and a link to
your site) to http://www.kegel.com/dkftpbench/Poller_bench.html
If you haven't already, you might peek at the discussion on
linux-kernel. Linus seems to be on the
Linus Torvalds wrote:
> > But user code currently written for poll() has the luxury of dropping
> > events because poll() will happily report on the current readiness of
> > the socket every time. /dev/poll is level-triggered because it's trying
> > to make conversion of poll()-based code easy.
Linus Torvalds wrote:
> > * Do you get an event whenever an fd is ready for something, or
> > only when its readiness changes? (Presumably whenever an fd is ready for
>something?)
>
> Only when its readiness changes - probably with the addition that it would
> simplify things that a new event
Linus Torvalds wrote:
> Basically, the main loop would boil down to
> for (;;) {
> static struct event ev_list[MAXEV];
> get_event(ev_list, MAXEV, &tmout);
> .. timeout handling here ..
> }
>
> because get_even() would end up doing a
Linus Torvalds wrote:
> Basically, the main loop would boil down to
>
> for (;;) {
> static struct event ev_list[MAXEV];
> get_event(ev_list, MAXEV, &tmout);
> .. timeout handling here ..
> }
>
> because get_even() would end up doin
Dan Kegel wrote:
> [kqueue is] Pretty similar to yours, with the following additions:
>
> Your proposal seems to only have one stream of available events per
> process. kqueue() returns a handle to an event queue, and kevent()
> takes that handle as a first parameter.
>
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Here's a suggested "good" interface that would certainly be easy to
> implement, and very easy to use, with none of the scalability issues that
> many interfaces have. ...
> It boils down to one very simple rule: dense arrays of sticky status
> inf
Nick Piggin ([EMAIL PROTECTED]) wrote:
> > I'm trying to write a server that handles 1 clients. On 2.4.x,
> > the RT signal queue stuff looks like the way to achieve that.
>
> I would suggest you try multiple polling threads. Not only will you get
> better SMP scalability, if you have say
David Schwartz wrote:
> > I'm trying to write a server that handles 1 clients. On 2.4.x,
> > the RT signal queue stuff looks like the way to achieve that.
> > Unfortunately, when the RT signal queue overflows, the consensus seems
> > to be that you fall back to a big poll(). And even though
Jordan Mendelson ([EMAIL PROTECTED]) wrote:
> An implementation of /dev/poll for Linux already exists and has shown to
> be more scalable than using RT signals under my tests. A patch for 2.2.x
> and 2.4.x should be available at the Linux Scalability Project @
> http://www.citi.umich.edu/projec
Linus Torvalds wrote:
> Dan Kegel wrote:
>> [ http://www.kegel.com/dkftpbench/Poller_bench.html ]
>> [ With only one active fd and N idle ones, poll's execution time scales
>> [ as 6N on Solaris, but as 300N on Linux. ]
>
> Basically, poll() is _fundamentally_ a
I ran a benchmark to see how long a call to poll() takes
as you increase the number of idle fd's it has to wade through.
I used socketpair() to generate the fd's.
Under Solaris 7, when the number of idle sockets was increased from
100 to 1, the time to check for active sockets with poll()
i
> I'd like to hear your opinions on the efficiency for the IPC mechanism
> betweeen two processes. (from a kernel point of view)
Have you read "Unix Network Programming, Volume 2, 2nd edition: IPC"
by Richard Stevens? It has measurements for this kind of thing
on two OS's, and you can run the
"David S. Miller" wrote:
> Please try this 2.2.x patch. It fixes the 2.2.x performance
> problem with your example code for me.
Will try when I get back from vacation. Thanks for the quick response!
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
I wrote a little benchmark to call either pipe() or socketpair()
8000 times, then close() on all the fds produced by pipe or socketpair.
On both 2.2.14 and 2.2.16, pipe and socketpair are nice and speedy.
close() is fine for pipes, but at 8000 socketpairs, each call to close()
takes 14 *millisec
OK, this isn't fair, but I just did a grep for AF_LOCAL in
/usr/include/*/*.h on my red hat 6.2 system, and found among others
the lines
/usr/include/bits/socket.h:#define AF_LOCALPF_LOCAL
/usr/include/linux/socket.h:#define PF_LOCALAF_LOCAL
which is a bit amusing... the gl
http://boudicca.tux.org/hypermail/linux-kernel/ is gone.
I was linking to individual posts there in my
pages about kernel enhancements. What happened?
Must I now laboriously link to some other archive? :-(
And what linux-kernel archive is likely to be around
long enough to be worth linking to?
G
Lee Chin ([EMAIL PROTECTED]) wrote:
> How do I increase the maximum number of socket connections I can have open
> in the 2.4 series kernel?
See http://www.kegel.com/c10k.html#limits.filehandles
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
http://www.kegel.com/c10k.html#zerocopy now links to
http://people.freebsd.org/~ken/zero_copy/ which describes
some patches for FreeBSD which add support for zero-copy
networking from user space.
Where they're headed is:
When transferring one or more pages via a page-alligned
buffer and norma
Rik van Riel wrote:
> > The only thing it can be a problem for an alternate VM if there
> > would be user<->kernel API differences realted to the very
> > internal of the memory management so if possible I'd like if
> > that could be avoided.
>
> Sure, lets get rid of /proc/meminfo ;)
>
>
jury gerold <[EMAIL PROTECTED]> wrote:
> When i create a connection (telnet a.b.c.d port) the signal is
> delivered depending on the user that does the telnet.
> If root creates the socket, then only root or another machine
> is able to trigger the signal by connecting to the socket.
> Normal
[EMAIL PROTECTED] wrote:
> Few month ago, I gathered precice data and posted it on lk-ml. In our
> experiment, I used four 100Base cards, the Web-Bench gained nearly 5%
> performance by the patch. The CPU load reached over 95%.
>
> I want to show the reference to experiments results, But unfor
Ingo Molnar ([EMAIL PROTECTED]) wrote:
> yep i agree - in this case a receivefile() implementation would be handy
> (we are 100% ready in 2.4 to introduce it - from the pagecache and VFS
> point of view, it's just not there yet), thus you could receivefile() your
> data into a temporary file, a
94 matches
Mail list logo
