On Wed, May 09, 2001 at 05:03:06PM +0200, Reto Baettig wrote:
> Jeff Garzik schrieb:
> >
> > Martin Dalecki wrote:
> > > > - I force the virtual blocksize for all the blkdev I/O
> > > > (buffered and direct) to work with a 4096 bytes granularity instead of
> > >
> > > You mean PAGE_SIZE :-).
>
On Wed, May 09, 2001 at 07:02:16PM -0300, Marcelo Tosatti wrote:
> Why don't you clean I_DIRTY_PAGES ?
we don't have visibilty on the inode_lock from there, we could make a
function in fs/inode.c or export the inode_lock to do that, but the flag
will be collected when the inode is released anywa
On Wed, May 09, 2001 at 07:38:01PM -0300, Marcelo Tosatti wrote:
>
>
> On Thu, 10 May 2001, Andrea Arcangeli wrote:
>
> > On Wed, May 09, 2001 at 07:02:16PM -0300, Marcelo Tosatti wrote:
> > > Why don't you clean I_DIRTY_PAGES ?
> >
> > we don&#
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote:
> On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
> > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1)
> > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling
> > > schedule(), an
On Thu, May 10, 2001 at 11:17:17PM +0200, Andi Kleen wrote:
> On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote:
> > On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote:
> > > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
> > > > >
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
> Please fix the binary incompatibility in the on disk format between the current
> code and your new release _before_ you do that. The last patches I was sent
> would have screwed every 64bit LVM user.
I just switched to the >=beta4 lvm I
Bootmem allocations are executed before all the reserved memory is been
reserved. This is the fix against 2.4.5pre1. This might explain weird
crashes and "reserved twice" error messages at boot on highmem systems.
I didn't yet had the confirm this patch hels but certainly it is a
necessary fix fo
On Fri, May 11, 2001 at 05:18:35PM +0100, Alan Cox wrote:
> > reserved. This is the fix against 2.4.5pre1. This might explain weird
> > crashes and "reserved twice" error messages at boot on highmem systems.
>
> Reserved twice occurs for two known reasons
>
> BIOS reporting the same region twic
On Sun, May 13, 2001 at 12:44:45AM +0900, root wrote:
>
> On UP2000 SMP with two 21264 CPU's running 2.4.5pre1aa1 and 2.2.19aa1,
> I am getting the following message:
>
> ===
>
> May 12 07:02:09 norma kernel: TSUNAMI machine check: vector=0x630 pc
On Fri, May 11, 2001 at 10:19:13PM -0700, David S. Miller wrote:
>
> Andrea Arcangeli writes:
> > you _must_ know very well what the mainteinance of that code means ;).
>
> Which is why I added the facility by which such ioctl conversions can
> be registered at runtime by
On Fri, May 11, 2001 at 06:29:27PM -0700, David S. Miller wrote:
> I think that's a bad decision, but it is your's.
Let me put it this way: after I get the first real life request from an
user with an useful case where a 32bit app needs to run the lvm ioctl it
will be truly easy to change my mind
This patch fixes the troubles generated by msync on /dev/fb0 or any
other device driver that exports reserved memory to userspace via shared
mapping.
--- 2.4.5pre1aa3/mm/filemap.c.~1~ Fri May 11 02:08:28 2001
+++ 2.4.5pre1aa3/mm/filemap.c Mon May 14 18:48:59 2001
@@ -1808,10 +1808,12 @@
Detailed description of 2.4.5pre2aa1 follows.
---
00_alpha-illegal-irq-1
Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number
is getting run.
(debugging)
00_alpha-ksyms-1
Export a
The main features of 2.2.20pre2aa1 are:
o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert)
o Support for 2T of RAM on alpha (me)
o RAW-IO (doable with bigmem enabled too). Improvements are also been
backported from 2.4.
o SMP scheduler improvements. (m
On Wed, May 16, 2001 at 11:03:27AM +0200, [EMAIL PROTECTED] wrote:
> David,
> I am using the gcc-3.0 snapshot of 14.5.2001 from codesourcery (i686 binary).
> I have now tried to mimic CPU=386 behaviour (patch posted yesterday night)
> and it compiles (just sound fails), by exchanging y and n in
>
On Tue, May 15, 2001 at 08:42:03PM -0300, Rik van Riel wrote:
> On Tue, 15 May 2001, Andrea Arcangeli wrote:
>
> > Detailed description of 2.4.5pre2aa1 follows.
>
> > 00_buffer-2
> >
> > Reschedule during oom while allocating buffers, still getblk
>
On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote:
> 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.
>
On Wed, May 16, 2001 at 02:52:04PM +0100, David Howells wrote:
>
> Hi Andrea:
>
> Here you go:
>
> /usr/local/bin/gcc -D__KERNEL__ -I/inst-kernels/linux-2.4.5-pre2-aa/include -Wall
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
>-mpreferred-stack-boundary=2 -march=i6
On Wed, May 16, 2001 at 10:25:32AM -0700, dean gaudet wrote:
> 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 ...
> >
> &g
On Wed, Mar 23, 2005 at 03:42:32PM -0800, Andrew Morton wrote:
> I'm suspecting here that we simply leaked a refcount on every darn
> pagecache page in the machine. Note how mapped memory has shrunk down to
> less than a megabyte and everything which can be swapped out has been
> swapped out.
>
>
e is
a bit simpler. I also verified it still compiles and works fine on x86
and x86-64.
Instead of the TIF_32BIT redefine, if you want to change x86-64 to use
TIF_32BIT too (instead of TIF_IA32), let me know.
Thanks.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- 2.6.12/arch/ppc64/Kcon
On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
> suggest I just don't do any control ? Or should I implement a double
> buffer scheme with software gain as well in the kernel driver ?
I recall to have sometime clicked on volume controls that weren't
hardware related, I don
ated). If you
prefer textual "disable" we can change this of course.
Comments welcome.
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: oom killer protection
iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECT
On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
> HZ=100 does not allow improving the idle loop much further
> from what we have. We should be able to take advantage of the
> longer idle/sleep periods inbetween the skipped ticks.
OTOH servers aren't just doing idle power saving, if
On Wed, Jan 19, 2005 at 10:19:47AM -0800, Tony Lindgren wrote:
> If you have a chance, can you please provide me with some more info
> on your system, see my recent reply to Pavel in this thread for the
It's a normal UP athlon 1ghz, it should be quite widespread hardware.
I know at least another s
On Wed, Jan 19, 2005 at 11:34:20AM -0800, Tony Lindgren wrote:
> It could be HPET that kills it. I don't have any boxes with HPET
> timer, can you try without HPET?
There's no hpet hardware in that system. Also the problem I'm having is
not with your patch but on some code that should be exercised
On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:
> On Thu, Jan 20, 2005 at 01:34:06PM +0100, Jens Axboe wrote:
>
> > Using current BK on my x86-64 workstation, it went completely nuts today
> > killing tasks left and right with oodles of free memory available.
>
> Yes, the fact th
On Thu, Jan 20, 2005 at 03:57:07PM -0600, Chris Friesen wrote:
> Andries Brouwer wrote:
>
> >But let me stress that I also consider the earlier situation
> >unacceptable. It is really bad to lose a few weeks of computation.
>
> Shouldn't the application be backing up intermediate results to disk
tweak is inherited between parent and child so it's easy to write a
wrapper for complex apps.
I made used_math a char at the light of later patches. Current patch
breaks alpha, but future patches will fix it.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- mainline/fs/proc/ba
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: keep balance between different classzones
This is the forward port to 2.6 of the lowmem_reserved algorithm I
invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
like google (especially without swap) on x86 with >
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: fix several oom killer bugs, most important avoid spurious oom kills
badness algorithm tweaked by Thomas Gleixner to deal with fork bombs
This is the core of the oom-killer fixes I developed partly taking the
idea from Thomas's
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: convert memdie to an atomic thread bitflag
On Sat, Dec 25, 2004 at 03:27:21AM +0100, Andrea Arcangeli wrote:
> So my current plan is to make used_math a PF_USED_MATH, and memdie a
> TIF_MEMDIE. And of course oomtaskadj an int (that
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: Convert the unsafe signed (16bit) used_math to a safe and optimal
PF_USED_MATH
On Sat, Dec 25, 2004 at 04:24:30AM +0100, Andrea Arcangeli wrote:
> Here it is the first part. This makes memdie a TIF_MEMDIE. It's
And her
lowmem
instead. This should prevent heavy block device writers from pushing
the VM over the edge and triggering OOM kills.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Acked-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- x/mm/page-writeback.c.orig 2005-01-04 01:13:30.
On Thu, Jan 20, 2005 at 10:20:56PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
&
On Thu, Jan 20, 2005 at 10:26:30PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This needed highmem fix from Rik is still missing too, so please apply
> > along the other 5 (it's orthogonal so you can apply this one in any
>
On Fri, Jan 21, 2005 at 05:36:14PM +1100, Nick Piggin wrote:
> I think it should be turned on by default. I can't recall what
I think it too, since the number of people that can be bitten by this is
certainly higher than the number of people who knows the VM internals
and for what kind of workload
Hugh. Sorry Hugh, I
know you were working on it (you said not in the weekend IIRC), but I've
been upgraded to latest bk so I had to fixup quickly or I would have to
run the racy code on my smp systems to test new kernels.
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: fixup smp r
On Thu, Jan 20, 2005 at 11:00:16PM -0800, Andrew Morton wrote:
> Last time we dicsussed this you pointed out that reserving more lowmem from
> highmem-capable allocations may actually *help* things. (Tries to remember
> why) By reducing inode/dentry eviction rates? I asked Martin Bligh if he
> co
On Fri, Jan 21, 2005 at 06:04:25PM +1100, Nick Piggin wrote:
> OK this is a fairly lame example... but the current code is more or
> less just lucky that ZONE_DMA doesn't usually fill up with pinned mem
> on machines that need explicit ZONE_DMA allocations.
Yep. For the DMA zone all slab cache wil
On Fri, Jan 21, 2005 at 08:08:21AM +0100, Andi Kleen wrote:
> So at least for GFP_DMA it seems to be definitely needed.
Indeed. Plus if you add pci32 zone, it'll be needed for it too on
x86-64, like for the normal zone on x86, since ptes will go in highmem
while pci32 allocations will not. So whil
On Fri, Jan 21, 2005 at 08:42:08AM +0100, Jens Axboe wrote:
> And especially not with 500MB of zone normal free, thanks :)
;) Are you sure you had 500m free even before the _first_ oom killing?
I assumed what you posted was not the first one of the oom killing
messages. If it was the first then t
On Fri, Jan 21, 2005 at 09:09:41AM +0100, Jens Axboe wrote:
> Jan 20 13:22:15 wiggum kernel: oom-killer: gfp_mask=0xd1
This was a GFP_KERNEL|GFP_DMA allocation triggering this. However it
didn't look so much out of DMA zone, there's 4M of ram free. Could be
the ram was relased by another CPU in th
Hello,
This is the seccomp patch ported to 2.6.11-rc1-bk8, that I need for
Cpushare (until trusted computing will hit the hardware market). This is
against 2.6.11-rc1-bk8. The progress is on schedule so far, so it might
not be a bad idea to merge this into the kernel sooner than later, so that
the
On Fri, Jan 21, 2005 at 01:47:01PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > This is the seccomp patch ported to 2.6.11-rc1-bk8, that I need for
> > > Cpushare (until trusted computing will hit the hardware market).
> > > [...]
> >
> > why do you need any ke
On Fri, Jan 21, 2005 at 08:55:22PM +0100, Ingo Molnar wrote:
>
> * Chris Wright <[EMAIL PROTECTED]> wrote:
>
> > * Rik van Riel ([EMAIL PROTECTED]) wrote:
> > > Yes, but do you care about the performance of syscalls
> > > which the program isn't allowed to call at all ? ;)
> >
> > Heh, no, but i
On Fri, Jan 21, 2005 at 09:54:16PM +0100, Ingo Molnar wrote:
> - the second barrier is the 'jail' of the ptraced task. Especially with
> PTRACE_SYSCALL, the things a child ptraced process can do are
> extremely limited, everything it tries to do will trap, the task will
> suspend and the pare
On Fri, Jan 21, 2005 at 05:27:11PM -0400, Mauricio Lin wrote:
> Hi Andrea,
>
> I applied your patch and I am checking your code. It is really a very
> interesting work. I have a question about the function
> __set_current_state(TASK_INTERRUPTIBLE) you put in out_of_memory
> function. Do not you th
On Fri, Jan 21, 2005 at 01:31:46PM -0800, Roland McGrath wrote:
> When gdb has a bug, people want to be able to kill it and get on with using
> their program, not have their program always be killed too.
What I need is that the program is killed right away synchronously as
soon as the "debugger" d
On Fri, Jan 21, 2005 at 05:45:13PM -0400, Mauricio Lin wrote:
> Hi Andrew,
>
> I have another question. You included an oom_adj entry in /proc for
> each process. This was the approach you used in order to allow someone
> or something to interfere the ranking algorithm from userland, right?
> So i
child so it's easy to write a
wrapper for complex apps.
I made used_math a char at the light of later patches. Current patch
breaks alpha, but future patches will fix it.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- x/fs/proc/base.c2005-01-15 20:44:58.0 +010
On Sat, Jan 22, 2005 at 11:32:42AM +0100, Pavel Machek wrote:
> Well, seccomp is also getting very little testing, when ptrace gets a
> lot of testing; I know that seccomp is simple, but I believe testing
> coverage still make ptrace better choice.
It's not testing that makes code more secure. Tes
On Sat, Jan 22, 2005 at 08:42:42PM +0100, Pavel Machek wrote:
> Well, then you can help auditing ptrace()... It is probably also true
> that more people audited ptrace() than seccomp :-).
Why should I spend time auditing ptrace when I have a superior solution
that doesn't require me any auditing a
On Sun, Jan 23, 2005 at 01:07:04AM +0100, Pavel Machek wrote:
> Adding code is easy, but in the long term would lead to maintainance
> nightmare. Adding seccomp code that does subset of ptrace, just
> because ptrace audit is lot of work, seems like a wrong thing to
> do. Sorry.
Even if I do the pt
On Sat, Jan 22, 2005 at 07:43:26PM -0500, Rik van Riel wrote:
> On Sun, 23 Jan 2005, Andrea Arcangeli wrote:
>
> >I'm doing something that requires the maximum level of
> >security ever,
>
> You're kidding, right ?
Why should I be kidding? The client code I
On Sat, Jan 22, 2005 at 11:43:06PM -0500, [EMAIL PROTECTED] wrote:
> It's a poor idea to confuse "secure" with "can't break out of the sandbox".
The only point I'm making with seccomp, is that if it can't break out of
the sandbox it's secure. I didn't mean that the only way to make it
secure is to
On Mon, Jan 24, 2005 at 10:45:47PM -0500, Dave Jones wrote:
> On Tue, Jan 25, 2005 at 02:19:24PM +1100, Andrew Tridgell wrote:
> > The problem I've hit now is a severe memory leak. I have applied the
> > patch from Linus for the leak in free_pipe_info(), and still I'm
> > leaking memory at the r
On Tue, Jan 25, 2005 at 02:31:03PM +0100, Andreas Gruenbacher wrote:
> On Tue, 2005-01-25 at 13:51, Andrea Arcangeli wrote:
> > If somebody could fix the kernel CVS I could have a look at the
> > interesting changesets between 2.6.11-rc1-bk8 and 2.6.11-rc2.
>
> What&#
Hello,
sorry to annoy you about this, but something is going wrong with either
cvsps or the kernel CVS.
I reproducibly get this as the last changeset, note the date. The
--bkcvs breaks completely too, but that would be a minor issue since
cvsps by default will get it right from the dates that are
On Tue, Jan 25, 2005 at 11:58:07AM -0500, Daniel Jacobowitz wrote:
> FYI, I haven't tried using cvsps on the kernel CVS, but I used to use it on
> GCC - and it fell down like this on a constant basis.
Interesting, for me it always worked fine on the kernel until last
month.
> You might want to ta
On Tue, Jan 25, 2005 at 05:10:17PM +, Catalin Marinas wrote:
> I noticed this problem some time ago when trying to see whether the
> darcs repository is consistent with the BK one:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
>
> A solution is to use the "(Logical ch
On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
> Sometimes the first application to be killed is XFree. AFAIK the
This makes more sense now. You need somebody trapping sigterm in order
to lockup and X sure traps it to recover the text console.
Can you replace this:
if (cap
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
> Actually I'd worked on what was called MPSS (Multiple Page Size Support)
> before I ever started on pgcl. Some large portion of the pgcl proposal
> as I presented it internally was to reduce the order of large page
> allocatio
On Tue, Jul 24, 2007 at 08:20:11PM -0700, William Lee Irwin III wrote:
> In any event, I've never been involved in a research project, though
I didn't mean it was supposed to be research project in some
University. But IIRC it was founded by what is defined as R&D in the
income statement of a publ
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
> I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help for
inefficient apps too. If
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
> I'm pretty sure the point of posting a patch that triples CFS performance
> on a certain benchmark and arguably improves the semantics of sched_yield
> was to improve CFS. You have a point, but it is a point for a different
> thread
On Mon, Jul 30, 2007 at 05:07:46PM -0400, Chris Snook wrote:
> [..] It's spending a lot less time in %sys despite the
> higher context switches, [..]
The workload takes 40% more so you've to add up that additional 40%
too into your math. "A lot less time" sounds an overstatement to
me. Also you'
On Wed, Aug 01, 2007 at 04:11:23AM -0400, Dan Merillat wrote:
> How expensive would it be to allocate two , then use the MMU mark the
> second page unwritable? Hardware wise it should be possible, (for
Tweaking kernel ptes is prohibitive during clone() because that's
kernel memory and it would re
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote:
> I've had several cases myself where I spent quite some time solving a
> problem, just to get some random remark from someone smart on lkml
> saying "if you had done you would have had simple and superior solution>". Was I pissed
Hello everyone,
This is a long thread about O_DIRECT surprisingly without a single
bugreport in it, that's a good sign that O_DIRECT is starting to work
well in 2.6 too ;)
On Fri, Jan 12, 2007 at 02:47:48PM -0800, Andrew Morton wrote:
> On Fri, 12 Jan 2007 15:35:09 -0700
> Erik Andersen <[EMAIL P
On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
> Dear Linux Developers/Enthusiasts,
>
> For a course at my university I'm implementing parts of an operating
> system where I get most ideas from the Linux Kernel (which I like very
> much). One book I gain information from is [1].
>
On Tue, Jan 23, 2007 at 07:01:33AM +0530, Balbir Singh wrote:
> This makes me wonder if it makes sense to split up the LRU into page
> cache LRU and mapped pages LRU. I see two benefits
> 1. Currently based on swappiness, we might walk an entire list
>searching for page cache pages or mapped pa
On Thu, Mar 01, 2007 at 12:12:28AM +0100, Ingo Molnar wrote:
> more capable by providing more special system calls like sys_upcall() to
> execute a user-space function. (that way a syslet could still execute
> user-space code without having to exit out of kernel mode too
> frequently) Or perhaps
Hi,
On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
> It's not inherent to ntpd's design, but the current (which may have been
> fixed since I looked last) implementation of the NTP PLL in the kernel.
>
> The interaction with ntpd can be fixed and I've done it in the past
> once,
On Mon, Jan 29, 2007 at 03:08:44PM +0100, Andrea Gelmini wrote:
> On Mon, Jan 22, 2007 at 10:10:39AM +0100, Peter Zijlstra wrote:
> > On Fri, 2007-01-12 at 01:39 +0100, Andrea Gelmini wrote:
> > > Hi,
> > > I can't do the test 'till next week.
> > >
> > > Thanks a lot for your time,
> > > Gelma
On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
> I still don't see much difference between O_SYNC and O_DIRECT write
> semantic.
O_DIRECT is about avoiding the copy_user between cache and userland,
when working with devices that runs faster than ram (think >=100M/sec,
quite standa
On Tue, Jan 30, 2007 at 01:50:41PM -0500, Phillip Susi wrote:
> It should return the number of bytes successfully written before the
> error, giving you the location of the first error. Also using smaller
> individual writes ( preferably issued in parallel ) also allows the
> problem spot to be
On Tue, Jan 30, 2007 at 08:57:20PM +0100, Andrea Arcangeli wrote:
> Please try yourself, it's simple enough:
>
>time dd if=/dev/hda of=/dev/null bs=16M count=100
>time dd if=/dev/hda of=/dev/null bs=16M count=100 iflag=sync
sorry, reading won't help much to
On Tue, Jan 30, 2007 at 06:07:14PM -0500, Phillip Susi wrote:
> It most certainly matters where the error happened because "you are
> screwd" is not an acceptable outcome in a mission critical application.
An I/O error is not an acceptable outcome in a mission critical app,
all mission critical
On Thu, Feb 01, 2007 at 12:20:59PM +0100, Andi Kleen wrote:
> I think a better way to do this would be to define a new
> CLOCK_THREAD_MONOTONOUS
> (or better name) timer for clock_gettime().
>
> [and my currently stalled vdso patches that implement clock_gettime
> as a vsyscall]
>
> Then also a
On Thu, Feb 01, 2007 at 01:02:41PM +0100, Andi Kleen wrote:
> I don't think so because having per process state in a vsyscall
> is quite costly. You would need to allocate at least one more
> page to each process, which I think would be excessive.
You would need one page per cpu and to check a cha
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 the first
place indeed.
If nothing else rdtscp should avoid the mess of restarting a
vsys
On Mon, Dec 11, 2006 at 03:15:44PM -0800, dean gaudet wrote:
> rdtscp gets you 2 of the 5 values you need to compute the time. anything
> can happen between when you do the rdtscp and do the other 3 reads: the
> computation is (((tsc-A)*B)>>N)+C where N is a constant, and A, B, C are
> per-cpu
On Sun, Jun 17, 2007 at 04:46:44PM -0300, Alexandre Oliva wrote:
> My perception is that the first easily dominates the second, and so
> you are better off without tivoization.
Your perception is quite flawed.
I see where you come from, I know your intentions are absolutely
genuine, but there's n
On Sun, Jun 17, 2007 at 04:58:40PM -0500, Chris Adams wrote:
> The reason is that if there ever is a security hole in the routing
> engine software (FreeBSD kernel, OpenSSH, etc.), it would be a really
> bad thing if crackers could load arbitrary software (rootkits, spam
> software, etc.) directly
On Mon, Jun 25, 2007 at 10:05:09PM +0100, Hugh Dickins wrote:
> size of memory?); but I rather think validate_anon_vma has outlived its
> usefulness, and is better just removed - which gives a magnificent
Probably yes. But the most fundamental issue is that this code
probably was never meant to be
On Wed, Jun 13, 2007 at 10:49:29AM +0200, John Sigler wrote:
> Question 1: why isn't this output picked up by klogd and sent to the
> appropriate file (kern.log in my case)?
I guess not a question for lkml, most distros uses syslog-ng anyway.
> Question 2: how can I tell which process or kernel
On Wed, Jun 13, 2007 at 09:10:33AM -0600, Chris Friesen wrote:
> Helge Hafting wrote:
>
> >My guess:
> >Something needs memory but finds there is none to be had
> >oom-killer is invoked and targets myapp.
> >myapp takes some time to die. Particularly, the memory it uses
> >isn't freed up instantly
# HG changeset patch
# User Andrea Arcangeli <[EMAIL PROTECTED]>
# Date 1181833362 -7200
# Node ID 8d75c4aa7185fcdcc2e99f3fe0f1ec68cbd78a43
# Parent 6416ccf1c2fa5f990695b38c8a692fa9e109a223
move seccomp from /proc to a prctl
This reduces the memory footprint and it enforces that only the c
Hello,
Those are two longstanding updates for seccomp that I need applied ASAP.
It's not the first time I submit them, hope they go in this time, for the
happiness of all the anti-seccomp and in turn anti-cpushare folks out there.
1) this reduces the number of bytes that seccomp takes when enabl
# HG changeset patch
# User Andrea Arcangeli <[EMAIL PROTECTED]>
# Date 1181833362 -7200
# Node ID a1896c3e29c7fb4dc1811f24e9f5cfc8dcbad419
# Parent 8d75c4aa7185fcdcc2e99f3fe0f1ec68cbd78a43
make seccomp zerocost in schedule
This follows a suggestion from Chuck Ebbert on how to make s
Hello,
for the hack week at opensuse (see http://idea.opensuse.org/) I've
been working on a new feature called CONFIG_PAGE_SHIFT.
In the last few days while reading the topics of the VM summit I
answered I disliked the dependency on defrag for reliable I/O and I
suggested I had an alternative des
On Fri, Jul 06, 2007 at 04:33:21PM -0700, Dave Hansen wrote:
> The patch looks really interesting, it's just a little hard to parse
> with all of the s/4096/PAGE_SIZE/ bits around. Those cleanups, along
> with the s/PAGE_SIZE/HARD_PAGE_SIZE/ parts would be great in a
> separated-out patch so that
On Fri, Jul 06, 2007 at 06:47:01PM -0700, Badari Pulavarty wrote:
> Hmm.. I didn't have any luck booting my machine with the patchset
> (with 8k pagesize) :(
>
> It fails to find the partition table on my hard drive.
I'm afraid I can't reproduce :( Best would be to track that code and
see what's
On Sat, Jul 07, 2007 at 05:01:57PM +1000, Paul Mackerras wrote:
> Andrea Arcangeli writes:
>
> > So my whole idea is to once and for all to decuple the size of the
> > pte-entry (4k on x86/amd64) with the page allocator granularity. The
> > HARD_PAGE_SHIFT will be 4
On Sat, Jul 07, 2007 at 08:53:49PM +0200, Jan Engelhardt wrote:
>
> On Jul 7 2007 00:26, Andrea Arcangeli wrote:
> >Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
>
> I wonder what happens if the soft page size gets set to 2048 bytes :)
Well the min allowed shift
On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
> I think you've misunderstood why large block sizes are important to
> XFS. The major benefits to XFS of larger block size have almost
> nothing to do with data layout or in memory indexing - it comes from
> metadata btree's getting m
Hi Andi,
On Wed, Jul 11, 2007 at 11:16:38PM +0200, Andi Kleen wrote:
> I thought it was clear that rip everything out is rarely a good idea
> in Linux land? That's really not something I should need to harp on
> repeatedly.
I'm going to change topic big time because your sentence above
perfectl
On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
> I need really large filesystems that contain both small and large files to
> work more efficiently on small boxes where we can't throw endless amounts of
> RAM and CPUs at the problem. Hence things like 64k page size are just not an
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> That's crap. Just because a machine has lots of memory does not
> make it OK to waste lots of memory.
It's not just wasted, it lowers overhead all over the place. Yes, the
benefit of wasting less pagecache may largely outweight the b
1101 - 1200 of 2012 matches
Mail list logo
