* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-08 0:55 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604081015.44771.kernel@kolivas.org>
Con Kolivas wrote:
> On Friday 07 April 2006 22:40, Nick Piggin wrote:
>
>>How would zone_watermark_ok always fail though?
>
>
> Withdrew this patch a while back; ignore
>
Well, whether or not that particular patch isa good idea, it
is definitely a bug if zone_watermark_ok could ever always
fail due to lowmem reserve and we should fix it.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* [ANNOUNCE] GIT 1.2.6
From: Junio C Hamano @ 2006-04-08 0:56 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.6.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.6-1.$arch.rpm (RPM)
These fixes are my birthday present to git ;-). I'll also do
the 1.3.0-rc3 tonight.
----------------------------------------------------------------
Changes since v1.2.5 are as follows:
Junio C Hamano:
parse_date(): fix parsing 03/10/2006
diff_flush(): leakfix.
count-delta: match get_delta_hdr_size() changes.
Nicolas Pitre:
check patch_delta bounds more carefully
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-08 1:01 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <443709F1.90906@yahoo.com.au>
On Saturday 08 April 2006 10:55, Nick Piggin wrote:
> Con Kolivas wrote:
> > On Friday 07 April 2006 22:40, Nick Piggin wrote:
> >>How would zone_watermark_ok always fail though?
> >
> > Withdrew this patch a while back; ignore
>
> Well, whether or not that particular patch isa good idea, it
> is definitely a bug if zone_watermark_ok could ever always
> fail due to lowmem reserve and we should fix it.
Ok. I think I presented enough information for why I thought zone_watermark_ok
would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
don't think I've ever seen that much free on my ZONE_DMA on an ordinary
desktop without any particular ZONE_DMA users. Changing the tunable can make
the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
understand the ratio.
--
-ck
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-08 1:01 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <443709F1.90906@yahoo.com.au>
On Saturday 08 April 2006 10:55, Nick Piggin wrote:
> Con Kolivas wrote:
> > On Friday 07 April 2006 22:40, Nick Piggin wrote:
> >>How would zone_watermark_ok always fail though?
> >
> > Withdrew this patch a while back; ignore
>
> Well, whether or not that particular patch isa good idea, it
> is definitely a bug if zone_watermark_ok could ever always
> fail due to lowmem reserve and we should fix it.
Ok. I think I presented enough information for why I thought zone_watermark_ok
would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
don't think I've ever seen that much free on my ZONE_DMA on an ordinary
desktop without any particular ZONE_DMA users. Changing the tunable can make
the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
understand the ratio.
--
-ck
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17.2
From: Petr Baudis @ 2006-04-08 1:06 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
to join the series of git-related announcements, Cogito-0.17.2, the next
maintenance release on the current stable (v0.17) branch of Cogito, the
human-friendly version control system on top of Git, is available now.
There are only very few changes, it looks that we are pretty stable:
Chris Wright:
cogito spec BuildRequires update
Dennis Stosberg:
cogito: Push tags over http
Petr Baudis:
Improved cg-version output (use cg-object-id -d)
cg-patch -c: Stop also at ^diff --git when slurping the commit message
Fixed embarassing cg-admin-rewritehist bug
Make cg-add/rm warnings less confusing: s/files/items/
cogito-0.17.2
P.S.: Visit us at #git @ FreeNode!
Happy hacking,
--
Petr "Stable Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
From: Jim Cromie @ 2006-04-08 1:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, johnstul
In-Reply-To: <20060407170706.1ae11ea1.akpm@osdl.org>
Andrew Morton wrote:
> Jim Cromie <jim.cromie@gmail.com> wrote:
>
>> FYI,
>>
>> as the 2 syslog extracts show;
>> 1. the new kernel is now detecting the buggy TSC on the GEODE-sc1100
>> 2. the bug is apparently correctable by passing 'idle=poll' on kernel
>> boot-line.
>>
>> Heres one vendor's bug/erratta description:
>> http://soekris.com/Issue0003.htm
>>
>>
>> Apr 7 11:42:01 truck kernel: [ 19.160016] Kernel command line:
>> console=ttyS0,115200n81 root=/dev/nfs
>> nfsroot=192.168.42.1:/nfshost/soekris
>> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0
>> panic=5 BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
>> Apr 7 11:42:01 truck kernel: [ 24.314851] Time: tsc clocksource has
>> been installed.
>> Apr 7 11:42:01 truck kernel: [ 29.977802] TSC appears to be running
>> slowly. Marking it as unstable
>> Apr 7 11:42:01 truck kernel: [ 20.460000] Time: pit clocksource has
>> been installed.
>>
>>
>> Apr 7 12:35:56 truck kernel: [ 21.562573] Kernel command line:
>> console=ttyS0,115200n81 root=/dev/nfs
>> nfsroot=192.168.42.1:/nfshost/soekris
>> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0
>> panic=5 idle=poll BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
>> Apr 7 12:35:56 truck kernel: [ 21.563049] using polling idle threads.
>> Apr 7 12:35:56 truck kernel: [ 28.393469] Time: tsc clocksource has
>> been installed.
>>
>>
>> Its nice to see the buggy TSC detector detect, and the work-around work.
>>
>
> hm.
>
> John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
> to merge after all your time-management patches have gone in?
>
>
that patch adds only MGEODE_LX, MGEODEGX1 was already there.
per the soekris link:
The net4801 board use a new single chip x86 processor from National
Semiconductor, the SC1100. It is based on the Cyrix GX1 core and the
CS5530 support chip, but has some difference. So far we have identified
the following issues that might need a patch to the operating system:
So, by a narrow reading, the current Kconfig already enables the TSC for
my board.
IOW, the patch doesnt worsen the situation. I dont know whether the bug
affects MGEODE_LX,
but it sounds like it could be a different core, w/o the bug.
The only folks possibly hurt by this patch are those who have
mis-selected MGEODE_LX
when they have a MGEODEGX1, and are currently protected from using the
buggy TSC.
my $.02, keep it in.
^ permalink raw reply
* Re: [spi-devel-general] Re: [PATCH] spi: Added spi master driver for Freescale MPC83xx SPI controller
From: David Brownell @ 2006-04-08 1:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: Vitaly Wool, Greg KH, linux-kernel, spi-devel-general
In-Reply-To: <CD0F0EAE-B3C0-4C03-BB90-99E65C16EC4F@kernel.crashing.org>
On Friday 07 April 2006 10:04 am, Kumar Gala wrote:
> > Well, not the _only_ way. The polling-type txrx_word() calls are
> > also full duplex. My point is more that it's bad/inefficient to
> > incur both IRQ _and_ task switch overheads per word, when it would
> > be a lot simpler to just have the IRQ handler do its normal job.
Not that you actually _need_ an IRQ handler to be correct, in any case.
> > (And that's even true if you've turned hard IRQ handlers into threads
> > for PREEMPT_RT or whatever. In that case the "IRQ overhead" is a
> > task switch, but you're still saving _additional_ task switches.)
>
> This makes more sense about what I'm doing that is wasteful.
> However, I'm not sure exactly where I should plug into things.
Only using interfaces below the line in spi_bitbang that says
it's the "SECOND PART".
> I think you are saying to continue using spi_bitbang_transfer &
> spi_bitbang_work, but have spi_bitbang_work call my own bitbang-
> >txrx_bufs().
Yes. Consider several different ways to implement that I/O loop:
- Interrupt plus two context switches per byte (what you have now),
no per-buffer context switch
- Interrupt per byte, plus one context switch pair per buffer
(what I've described)
- pure PIO per byte, no context switches (as if you polled
the registers rather than using an IRQ)
Any of them could be correct, but one of them is a lot worse in terms
of CPU overhead when you aim at tranfer rates of even just a few MBytes
per second. (It's the one with lots of needless context switching.)
That pure PIO model will sometimes be very appropriate; if the SPI clock
is fast enough, it can be less overhead than the IRQ driven one.
- Dave
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-08 1:25 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604081101.06066.kernel@kolivas.org>
Con Kolivas wrote:
> On Saturday 08 April 2006 10:55, Nick Piggin wrote:
>
>>Con Kolivas wrote:
>>
>>>On Friday 07 April 2006 22:40, Nick Piggin wrote:
>>>
>>>>How would zone_watermark_ok always fail though?
>>>
>>>Withdrew this patch a while back; ignore
>>
>>Well, whether or not that particular patch isa good idea, it
>>is definitely a bug if zone_watermark_ok could ever always
>>fail due to lowmem reserve and we should fix it.
>
>
> Ok. I think I presented enough information for why I thought zone_watermark_ok
> would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
> lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
> don't think I've ever seen that much free on my ZONE_DMA on an ordinary
> desktop without any particular ZONE_DMA users. Changing the tunable can make
> the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
> understand the ratio.
>
Umm, for ZONE_DMA allocations, ZONE_DMA isn't a lower zone. So that
12MB protection should never come into it (unless it is buggy?).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* 2.6.16-ck4
From: Con Kolivas @ 2006-04-08 1:25 UTC (permalink / raw)
To: ck list, linux list
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
These are patches designed to improve system responsiveness and interactivity.
It is configurable to any workload but the default ck patch is aimed at the
desktop and cks is available with more emphasis on serverspace.
THESE INCLUDE THE PATCHES FROM 2.6.16.2 SO START WITH 2.6.16 AS YOUR BASE
Apply to 2.6.16
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.16/2.6.16-ck4/patch-2.6.16-ck4.bz2
or server version
http://www.kernel.org/pub/linux/kernel/people/ck/patches/cks/patch-2.6.16-cks4.bz2
web:
http://kernel.kolivas.org
all patches:
http://www.kernel.org/pub/linux/kernel/people/ck/patches/
Split patches available.
Changes:
Modified:
-patch-2.6.16.1
+patch-2.6.16.2
Resync with mainline
-2.6.16-ck3-version.patch
+2.6.16-ck4-version.patch
Version update
--
-ck
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Peter Williams @ 2006-04-08 1:29 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel
In-Reply-To: <200604080032.28911.a1426z@gawab.com>
Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Peter Williams wrote:
>>>> Al Boldi wrote:
>>>>> Peter Williams wrote:
>>>>>> Al Boldi wrote:
>>>>>>>>>> Control parameters for the scheduler can be read/set via files
>>>>>>>>>> in:
>>>>>>>>>>
>>>>>>>>>> /sys/cpusched/<scheduler>/
>>>>>>> The default values for spa make it really easy to lock up the
>>>>>>> system.
>>>>>> Which one of the SPA schedulers and under what conditions? I've been
>>>>>> mucking around with these and may have broken something. If so I'd
>>>>>> like to fix it.
>>>>> spa_no_frills, with a malloc-hog less than timeslice. Setting
>>>>> promotion_floor to max unlocks the console.
>>>> OK, you could also try increasing the promotion interval.
>>> Seems that this will only delay the lock in spa_svr but not inhibit it.
>> OK. But turning the promotion mechanism off completely (which is what
>> setting the floor to the maximum) runs the risk of a runaway high
>> priority task locking the whole system up. IMHO the only SPA scheduler
>> where it's safe for the promotion floor to be greater than MAX_RT_PRIO
>> is spa_ebs. So a better solution is highly desirable.
>
> Yes.
>
>> I'd like to fix this problem but don't fully understand what it is.
>> What do you mean by a malloc-hog? Would it possible for you to give me
>> an example of how to reproduce the problem?
>
> Can you try the attached mem-eater passing it the number of kb to be eaten.
>
> i.e. '# while :; do ./eatm 9999 ; done'
>
> This will print the number of bytes eaten and the timing in ms.
>
> Adjust the number of kb to be eaten such that the timing will be less than
> timeslice (120ms by default for spa). Switch to another vt and start
> pressing enter. A console lockup should follow within seconds for all spas
> except ebs.
This doesn't seem to present a problem (other than the eatme loop being
hard to kill with control-C) on my system using spa_ws with standard
settings. I tried both UP and SMP. I may be doing something wrong or
perhaps don't understand what you mean by a console lock up. When you
say "less than the timeslice" how much smaller do you mean?
Peter
PS I even managed to do a kernel build with the eatme loop running on a
single processor system.
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: How to know when file data has been flushed into disk?
From: Xin Zhao @ 2006-04-08 1:39 UTC (permalink / raw)
To: Zach Brown; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <4436A770.3080905@zabbo.net>
This answered all my questions! Many thanks! Will check the phase 2 code.
Xin
On 4/7/06, Zach Brown <zab@zabbo.net> wrote:
>
> > If a program access data like this:
> >
> > 1. open the file
> > 2. write a lot of data into this file
>
> You don't say if this is an extending write or overwriting existing file
> data. I'm going to assume extending writes so that data=ordered kicks in.
>
> > 3. close the file
>
> > So my questions are:
> > 1. How will the file system be notified after all data has been
> > flushed into disk?
>
> Look at phase 2 in journal_commit_transaction(). The kjournald thread
> issues the writeback of the file data by walking t_sync_datalist and
> then waits for the writeback to complete by using wait_on_buffer()
> before committing the transaction.
>
> > 2. Unlike data=journal mode, in data=order mode, the data could be
> > lost if system crashes when data is being flushed to disk. When system
> > reboots, does journal contains the old meta data for undo?
>
> No, ext3 isn't roll-backward. It doesn't store the *old* data in the
> journal and undo the change if it fails halfway through. It's
> roll-forward. It stores the *new* data in the journal and replays
> complete transactions in the journal that weren't moved out to their
> final place on disk at the time of the crash.
>
> So if the machine reboots during the writeback phase then the
> transaction won't be committed yet and recovery won't replay that
> transaction from the journal. From the metadata's point of view the
> file extension will never have happened.
>
> > 3. Does sys_close() have to be blocked until all data and metadata
> > are committed?
>
> No, and neither does sys_getpid() :)
>
> > to take subsequent operation. However, data flush could be failed. In
> > this case, file system seems to mislead the application. Is this true?
>
> No. The application has no grounds for assuming that a successful
> close() has synced previous operations to disk. It's simply not part of
> the API.
>
> > If so, any solutions?
>
> The application should rely on tools like fsync(), fdatasync(), O_SYNC,
> mount -o sync, etc. Whatever suits it best.
>
> - z
>
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-08 1:25 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604081101.06066.kernel@kolivas.org>
Con Kolivas wrote:
> On Saturday 08 April 2006 10:55, Nick Piggin wrote:
>
>>Con Kolivas wrote:
>>
>>>On Friday 07 April 2006 22:40, Nick Piggin wrote:
>>>
>>>>How would zone_watermark_ok always fail though?
>>>
>>>Withdrew this patch a while back; ignore
>>
>>Well, whether or not that particular patch isa good idea, it
>>is definitely a bug if zone_watermark_ok could ever always
>>fail due to lowmem reserve and we should fix it.
>
>
> Ok. I think I presented enough information for why I thought zone_watermark_ok
> would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
> lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
> don't think I've ever seen that much free on my ZONE_DMA on an ordinary
> desktop without any particular ZONE_DMA users. Changing the tunable can make
> the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
> understand the ratio.
>
Umm, for ZONE_DMA allocations, ZONE_DMA isn't a lower zone. So that
12MB protection should never come into it (unless it is buggy?).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: Detecting deadlocks with hypervisor..
From: T S @ 2006-04-08 1:47 UTC (permalink / raw)
To: aliguori; +Cc: rthelen, Xen-devel, ewan, edwin.zhai
In-Reply-To: <4436A440.90704@us.ibm.com>
>From: Anthony Liguori <aliguori@us.ibm.com>
>To: T S <thileepan_@hotmail.com>
>CC: ewan@xensource.com, edwin.zhai@intel.com, rthelen@netapp.com,
>Xen-devel@lists.xensource.com, Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
>Subject: Re: [Xen-devel] Detecting deadlocks with hypervisor..
>Date: Fri, 07 Apr 2006 12:41:20 -0500
>
>T S wrote:
>>>From: Anthony Liguori <aliguori@us.ibm.com>
>>>To: T S <thileepan_@hotmail.com>
>>>CC: xen-devel@lists.xensource.com
>>>Subject: Re: [Xen-devel] Detecting deadlocks with hypervisor..
>>>Date: Fri, 24 Mar 2006 13:24:46 -0600
>>>
>>>T S wrote:
>>>>This may sound a silly question (pardon me because i am relatively new
>>>>to linux kernel) .. will it be possible to continue running reboot.c (or
>>>>for that matter any kernel thread) when the kernel is deadlocked ? In
>>>>Linux, is the kernel a single process or a bunch of parallelly executing
>>>>entities? If later, then during a kernel deadlock (eg: by loading a
>>>>faulty module that disables interrupts and do something silly) there can
>>>>still be some other processes/threads run, right?
>>>
>>>Sorry for not making this more clear previously. You cannot restore a
>>>dead-locked domain if a normal xm save doesn't work. One thing that makes
>>>Xen unique is that guests actually are aware of what physical pages are
>>>assigned to them. When one does a save/restore, the guest has to
>>>canonicalize all of it's internal references to physical pages. When it's
>>>restored, it then remaps it's newly assigned physical pages to all the
>>>old places where it needed to know about them for some reason or another.
>>
>>We took a look at the xc_linux_save() function ... and what we see is that
>>the canonicalize action is actually done by the Dom-0 (and not by the
>>Dom-U);
>
>Take a look at linux-2.6-sparse/drivers/core/reboot.c:__do_suspend().
>Canonicalization is done both in Dom-0 and in the guest itself. Dom-0
>attempts to do as much of it as it can but as I've said before, it cannot
>do all of it.
Anthony,
Thank you for your reply.
In linux-2.6-sparse/drivers/core/reboot.c:__do_suspend(), we see store_mfn
and console_mfn being canonicalized before the guest-OS goes to sleep (as
done in "xm save"). But before this canonicalization took place the python
layer writes the store_mfn and console_mfn into the save-file (in the file's
header area).
Does this mean the store_mfn and console_mfn values present in the header of
the file are re-written at a later part of the file ?
Other than the store & console mfn's are there any other parameters
canoicalized BY the guest OS during "xm save" ?
thanks.
>
>>Also, given that Dom-0 can access the page tables and other structures of
>>the deadlocked guest,
>>can one of you be able to tell me what changes I need to do to
>>xm_linux_save( ) (and other related functions) to save the state of the
>>deadlocked guest without doing any handshake with the guest OS ?
>
>If you want to attempt to futz with the state of a guest while it's running
>without the guest cooperating, your best bet is to do as Keir suggested and
>pause the domain, make your changes, and then unpause.
>
>Regards,
>
>Anthony Liguori
>
>>
>>thanks!
>>- T
>>
>>
>>>If the guest isn't responsive when you do a save, then it will never
>>>canonicalize itself and there is no way to restore the domain.
>>>
>>>Regards,
>>>
>>>Anthony Liguori
>>>
>>>>thanks
>>>>TS
>>>>
>>>>>
>>>>>If a suspend completes correctly, Xend will see it (another watch will
>>>>>fire),
>>>>>and xc_linux_save will be free to complete the save.
>>>>>
>>>>> > Also, does it seem viable to clone a copy of a deadlocked guest OS
>>>>>in the
>>>>> > first place?
>>>>>
>>>>>If you have a byte-for-byte copy of a deadlocked guest, even if you
>>>>>could
>>>>>suspend it, surely it will be deadlocked when it is resumed. How do you
>>>>>intend to break the deadlock, and how is it easier to do that from
>>>>>outside
>>>>>than it is to perform deadlock detection in the guest?
>>>>>
>>>>>Ewan.
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Xen-devel mailing list
>>>>>Xen-devel@lists.xensource.com
>>>>>http://lists.xensource.com/xen-devel
>>>>
>>>>_________________________________________________________________
>>>>Express yourself instantly with MSN Messenger! Download today - it's
>>>>FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>
>>>>
>>>>_______________________________________________
>>>>Xen-devel mailing list
>>>>Xen-devel@lists.xensource.com
>>>>http://lists.xensource.com/xen-devel
>>>
>>
>>_________________________________________________________________
>>Don’t just search. Find. Check out the new MSN Search!
>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>>
>
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
^ permalink raw reply
* Re: libnetfilter_queue conditions required to rewrite packets...
From: Mike Auty @ 2006-04-08 1:50 UTC (permalink / raw)
To: David Vogt; +Cc: netfilter
In-Reply-To: <859616420604070655n35ced2eau5c6968f5d2e3f029@mail.gmail.com>
Looks as though,
The code in the subversion repository's quite different, so I've
checked out a copy of that and I'm gonna give it a test when I next get
a chance. It requires >=libnfnetlink-0.0.16, so that's also gonna have
to be built from subversion.
The changes include incrementing the size of the structure to include
the size of the payload, and also the structure holding the payload is
defined outside the conditional statement. These I think, should mean
the packet's better formed and hopefully will do the actual mangling...
I'm not sure how far away those packages are from becoming releases,
but it seems they have some definite enhancements in them...
Mike 5:)
^ permalink raw reply
* Possible problem in activate_task() with priority inheritance in 2.6.17-rc1-mm1
From: Peter Williams @ 2006-04-08 1:55 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linux Kernel Mailing List
In activate_task() the call to recalc_task_prio() is guarded by
!rt_task(). This will suppress the recalculation of normal_prio for non
RT tasks that just happen to be at real time priority as a result of
priority inheritance. Is that intentional?
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* install.sh doesn't do a depmod (3.0.2)
From: James Harper @ 2006-04-08 2:11 UTC (permalink / raw)
To: xen-devel
Maybe that is the correct behaviour, but when I did './install.sh' from
the 'dist' directory, and then a mkinitramfs, it didn't give me any
modules in my ramdisk, which would have been a pita had I not noticed.
Imho, anything which installs modules should do a 'depmod -a <version>'.
The worst thing that would happen is that it would be run twice.
Or maybe mkinitramfs should be checking that the module dependency
information exists...
Thanks
James
^ permalink raw reply
* Full duplex mode
From: Carlos Munoz @ 2006-04-08 2:32 UTC (permalink / raw)
To: alsa-devel
Hi all,
An alsa driver I've written supports full duplex mode (playback and
capture simultaneously). Do I need to anything special to support full
duplex mode ? I assume the playback_open(), etc and capture_open(), etc
will both get called and from the driver point of view I'm just handling
two streams, right ?
Thanks,
Carlos
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: git/cogito suggestion: tags with descriptions
From: Petr Baudis @ 2006-04-08 2:35 UTC (permalink / raw)
To: Zack Brown; +Cc: Junio C Hamano, git
In-Reply-To: <20050912010051.GJ15630@pasky.or.cz>
Dear diary, on Mon, Sep 12, 2005 at 03:00:51AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Mon, Sep 05, 2005 at 11:24:31PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > I'm not sure. I'm not as familiar with the low-level git commands as I am with
> > cogito. But cogito has a -d option for giving a tag description. I guess what
> > would be closest to what I was thinking about would be this:
> >
> > $ cg-tag -d "First draft, everything in place." 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $ cg-tag-ls
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $
> >
> > or something like that. Currently when I do the above cg-tag command,
> > a subsequent cg-tag-ls gives just:
> >
> > $ cg-tag-ls
> > 0.1 f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> >
> > In fact, I probably wouldn't even be interested in seeing the actual hash key
> > unless I gave a special flag, maybe -f (for "full"):
> >
> > $ cg-tag-ls
> > 0.1 Initial idea complete
> > 0.3 First draft, everything in place.
> > $ cg-tag-ls -f
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
>
> That's a nice idea (except that I'd prefer -l). I'll implement this
> after cogito-0.14.
So, I did. ;-) (In the master branch now.) The format is slightly
different from the proposed one:
S cogito-0.16rc2 7766e3ba0664
S cogito-0.17 51392f2dd82a Poetic cogito-0.17.
S cogito-0.17rc1 7cb4d8972d5b Behold, cogito-0.17rc1! Plenty new features and cool stuff.
% cogito-0.8 f9f0459b5b39
% cogito-0.9 cc5517b4ea41
test 05862786175d
Object IDs are still shown, but abbreviated so they shouldn't get in the
way too much; the full first line is shown in the list output,
untrimmed. The initial flag column denotes signed tags by 'S', "direct
tags" (not pointing to a tag object) by '%' and broken tags by '!'.
P.S.: Also, cg-tag received a lot of improvements in the last two days.
Now features the same cool editor as cg-commit (but only if ran with
-e), -d was renamed to -m (but will stay aliased for quite some time),
cg-tag now also accepts multiple -m options for creating multi-paragraph
descriptions from the commandline, and bunch of other minor stuff was
implemented.
Thanks for the idea,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] ipmi: fix event queue limit
From: Corey Minyard @ 2006-04-08 2:51 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm
The event handler mechanism in the IPMI driver had a limit on the
number of received events, but the counts were not being updated.
Update the counts to impose a limit. This is not a critical fix,
as this function (the sending of the events) has to be turned on
by the user, anyway. This avoids problems if they forget to
turn it back off.
Signed-off-by: Corey Minyard <minyard@acm.org>
Index: linux-2.6.16/drivers/char/ipmi/ipmi_msghandler.c
===================================================================
--- linux-2.6.16.orig/drivers/char/ipmi/ipmi_msghandler.c
+++ linux-2.6.16/drivers/char/ipmi/ipmi_msghandler.c
@@ -941,6 +941,7 @@ int ipmi_set_gets_events(ipmi_user_t use
list_del(&msg->link);
list_add_tail(&msg->link, &msgs);
}
+ intf->waiting_events_count = 0;
}
/* Hold the events lock while doing this to preserve order. */
@@ -2917,6 +2918,7 @@ static int handle_read_event_rsp(ipmi_sm
copy_event_into_recv_msg(recv_msg, msg);
list_add_tail(&(recv_msg->link), &(intf->waiting_events));
+ intf->waiting_events_count++;
} else {
/* There's too many things in the queue, discard this
message. */
^ permalink raw reply
* [PATCH] 2.4 nfs cache consistency problem with mmap'ed files
From: Jeff Layton @ 2006-04-08 2:59 UTC (permalink / raw)
To: nfs; +Cc: marcelo.tosatti
This problem was reported to Red Hat and while fixing it for RHEL3, I
noticed that it was also a problem in the 2.4 git tree. The steps to
reproduce are a bit convoluted, so hopefully I'm explaining this well
enough. Let me know if you need clarification:
1) on a server create a file in an exported directory with some data in
it:
$ echo 1 > testfile
2) on an NFS client have a program mmap the file and access the data via
the mmap (effectively loading the pagecache with data from the server),
then have the program go to sleep indefinitely.
3) on the server, make a change to the file:
$ echo 2 > testfile
4) on the client, have another process cause a read:
$ cat /nfs/mounted/directory/testfile
You'll get the originally cached data (the 1), since the file is still
mmap'ed. This is expected.
5) on the client, kill the program that has the file mmap'ed and cat the
file again. You will still get the original file contents (the "1"
here).
The file is no longer mmap'ed, the data in the file and the mtime has
changed since the last OTW read, but the client will not invalidate the
cache for subsequent reads.
What's happening is that in step 4, the __nfs_refresh_inode function
updates NFS_CACHE_MTIME. But, because the file is still mmap'ed,
invalidate_inode_pages is not completely successful. So on the next pass
through, it assumes the cached data is good when it isn't.
The attached patch fixes this by checking whether the clean_pages list
for the inode is empty after invalidate_inode_pages is called. If not,
then we set a new nfs_i flag (NFS_INO_MAPPED). Then, on the next pass
through this function, we check the status of this flag and if it's set,
we clear it and set invalid=1 so that the function will make another
attempt at invalidating the cache.
This fixed the problem on my test rig. Comments and/or suggestions are
welcome.
-- Jeff
-----------[snip]-----------
--- linux-2.4/fs/nfs/inode.c.nfs-cache-fix
+++ linux-2.4/fs/nfs/inode.c
@@ -1047,6 +1047,13 @@ __nfs_refresh_inode(struct inode *inode,
invalid = 0;
}
+ /* set the invalid flag if the last attempt at invalidating
+ * the inode didn't empty the clean_pages list */
+ if ( NFS_FLAGS(inode) & NFS_INO_MAPPED) {
+ NFS_FLAGS(inode) &= ~NFS_INO_MAPPED;
+ invalid = 1;
+ }
+
/*
* If we have pending writebacks, things can get
* messy.
@@ -1092,6 +1099,12 @@ __nfs_refresh_inode(struct inode *inode,
NFS_ATTRTIMEO(inode) = NFS_MINATTRTIMEO(inode);
NFS_ATTRTIMEO_UPDATE(inode) = jiffies;
invalidate_inode_pages(inode);
+ if (! list_empty(&inode->i_mapping->clean_pages)) {
+ dfprintk(PAGECACHE,
+ "NFS: clean_pages for %x/%d is not empty\n",
+ inode->i_dev, inode->i_ino);
+ NFS_FLAGS(inode) |= NFS_INO_MAPPED;
+ }
memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode)));
} else if (time_after(jiffies, NFS_ATTRTIMEO_UPDATE(inode)+NFS_ATTRTIMEO(inode))) {
if ((NFS_ATTRTIMEO(inode) <<= 1) > NFS_MAXATTRTIMEO(inode))
--- linux-2.4/include/linux/nfs_fs_i.h.nfs-cache-fix
+++ linux-2.4/include/linux/nfs_fs_i.h
@@ -85,6 +85,7 @@ struct nfs_inode_info {
#define NFS_INO_REVALIDATING 0x0004 /* revalidating attrs */
#define NFS_IS_SNAPSHOT 0x0010 /* a snapshot file */
#define NFS_INO_FLUSH 0x0020 /* inode is due for flushing */
+#define NFS_INO_MAPPED 0x0040 /* page invalidation failed */
/*
* NFS lock info
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: RT task scheduling
From: Steven Rostedt @ 2006-04-08 3:01 UTC (permalink / raw)
To: Bill Huey
Cc: Darren Hart, Ingo Molnar, linux-kernel, Thomas Gleixner,
Stultz, John, Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060407233631.GA17574@gnuppy.monkey.org>
Hi Bill,
I'm just catching up on this thread. Is your main concern that a High
prio task is going to be unnecessary delayed because there's a lower RT
task on the same CPU and time is needed to push it off to another CPU?
It's late, so forgive me if this is a stupid question ;)
On Fri, 2006-04-07 at 16:36 -0700, Bill Huey wrote:
> > Has this cleared some things up? If not, let me know what else needs
> > clarification.
>
> Yes, but you should really work to clarify terminology. Is this better ?
Goes both ways :)
-- Steve
PS. It's really good to see you back on LKML. I've missed your posts.
^ permalink raw reply
* Re: [PATCH] inotify: check for NULL inode in inotify_d_instantiate
From: Nick Piggin @ 2006-04-08 3:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Nick Piggin, cbe-oss-dev, linux-kernel
In-Reply-To: <200604071808.41953.arnd.bergmann@de.ibm.com>
On Fri, Apr 07, 2006 at 06:08:41PM +0200, Arnd Bergmann wrote:
> The spufs file system creates files in a directory before instantiating
> the directory itself, which causes a NULL pointer access in
> inotify_d_instantiate since c32ccd87bfd1414b0aabfcd8dbc7539ad23bcbaa.
>
> I'd like to keep this behavior since it means that the user
> will not have access to files in the directory before I know
> that I succeed in creating everything in it. This patch adds
> a simple check for the inode to keep that working.
>
If this were not the correct thing to do, it is not the
business of c32ccd87bfd1414b0aabfcd8dbc7539ad23bcbaa to
prevent it. Thanks.
Acked-by: Nick Piggin <npiggin@suse.de>
> Cc: Nick Piggin <npiggin@suse.de>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> ---
>
> diff --git a/fs/inotify.c b/fs/inotify.c
> index 367c487..1f50302 100644
> --- a/fs/inotify.c
> +++ b/fs/inotify.c
> @@ -538,7 +538,7 @@ void inotify_d_instantiate(struct dentry
> WARN_ON(entry->d_flags & DCACHE_INOTIFY_PARENT_WATCHED);
> spin_lock(&entry->d_lock);
> parent = entry->d_parent;
> - if (inotify_inode_watched(parent->d_inode))
> + if (parent->d_inode && inotify_inode_watched(parent->d_inode))
> entry->d_flags |= DCACHE_INOTIFY_PARENT_WATCHED;
> spin_unlock(&entry->d_lock);
> }
^ permalink raw reply
* Re: [PATCH] Script for automated historical Git tree grafting
From: Petr Baudis @ 2006-04-08 3:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: torvalds, linux-kernel, git
In-Reply-To: <20060406175246.3bd1c972.akpm@osdl.org>
Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> >
> > This script enables Git users to easily graft the historical Git tree
> > (Bitkeeper history import) to the current history.
>
> What impact will that have on the (already rather poor) performance of
> git-whatchanged, gitk, etc?
Negative. ;-)
I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
the whole tree should be roughly equally fast as it was before grafting,
but git-whatchanged on individual paths is _significantly_ slower.
That said, 1.3.0rc2 should already have Linus' optimization which should
fix or at least mitigate the performance hit on narrowed-down
git-whatchanged.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [Qemu-devel] Translation cache sizes
From: Julian Seward @ 2006-04-08 3:13 UTC (permalink / raw)
To: qemu-devel
Using qemu from cvs simulating x86-softmmu (no kqemu) on x86,
booting SuSE 9.1 and getting to the xdm (kdm?) graphical login
screen, requires making about 1088000 translations, and the
translation cache is flushed 17 times. Booting is not too bad,
but once user-mode starts to run the translation cache is pretty
much hammered.
I made 2 changes:
* increase CODE_GEN_BUFFER_SIZE from 16*1024*1024
to 64*1024*1024,
* observe that CODE_GEN_AVG_BLOCK_SIZE of 128
for the softmmu case is too low; my measurements put it
at about 247. So I changed it to 256.
With those changes in place, the same boot-to-kdm process
requires only about 570000 translations to be made, and 2
cache flushes to happen. Of course the cost is an extra
48M of memory use.
J
^ permalink raw reply
* Re: [linux-lvm] LVM over IP network
From: Zac Slade @ 2006-04-08 3:16 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <1144412972.44365b2c36361@mail.sify.com>
On Friday 07 April 2006 07:59, rarulselvan@sify.com wrote:
> I do understand that LVM and EVMS are quite useful for managing the disk
> space in given work station. So I am wondering if there is such thing as
> LVM over IP network ? so that I can maximize my disk usage. If not, what is
> my other choice ?
Why not? Using iSCSI or ATAoE you can export the extra space from each of the
system as devices that will appear to be block devices. From there you can
add them to a vg anytime you want. Just be careful how you do it because if
one of the systems goes off the network you will not have access to the data
from that drive. Also I'm not so sure how well LVM deals with having a drive
dissappear out from underneath it.
--
Zac Slade
krakrjak@volumehost.net
ICQ:1415282 YM:krakrjak AIM:ttyp99
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.