headers
Frederik Deweerdt | 1 Aug 2006 11:06
Picon
Favicon

Re: [01/04 mm-patch, rfc] Add lightweight rwlock

On Mon, Jul 31, 2006 at 04:06:15PM +0900, Masatake YAMATO wrote:
Hi,
> > The following set of patches adds a struct lw_rwlock (for lightweight
> > rwlock) which contains a spin_lock_t and an atomic_t. It is defined
> > in include/linux/lw_rwlock.h.
> 
> I think the name, "lightweight" is too generic. 
Fair enough.
> It implies just lw_rwlock is better than rwlock. The name may lead that people 
> use lw_rwlock rather than rwlock any place through there are places where 
> rwlock is better than lw_rwlock. So I looked for the name:
> 
> sw_rwlock: seldom writing rwlock
> wp_rwlock: write pricey rwlock

write expensive, we_rwlock? I like your idea of stressing the fact that
the protected data has to be seldom modified if you intend to use this
kind of lock.

> rp_rwlock: read prioritized rwlock
> 
I'll re-submit the patch with a proper naming for the rc3-mm1. However, I'd
like to get some feedback on the code itself: the current
whatever_rwlock code won't be debuggable with lockdep, and I'm not sure
there's not some more clever way to do it.

Thanks,
Frederik
Permalink | Reply | 0 comments |
headers
Oleg Nesterov | 1 Aug 2006 02:12
Picon

Re: rt_mutex_timed_lock() vs hrtimer_wakeup() race ?

On 07/30, Steven Rostedt wrote:
>
> On Sun, 2006-07-30 at 08:36 +0400, Oleg Nesterov wrote:
> > 
> > Another question, task_blocks_on_rt_mutex() does get_task_struct() and checks
> > owner->pi_blocked_on != NULL under owner->pi_lock. Why ? RT_MUTEX_HAS_WAITERS
> > bit is set, we are holding ->wait_lock, so the 'owner' can't go away until
> > we drop ->wait_lock.
> 
> That's probably true that the owner can't disappear before we let go of
> the wait_lock, since the owner should not be disappearing while holding
> locks.  But you are missing the point to why we are grabbing the
> pi_lock.  We are preventing a race that can have us do unneeded work
> (see below).

Yes, I see. But ...

> ===================================================================
> --- linux-2.6.18-rc2.orig/kernel/rtmutex.c	2006-07-30 18:04:12.000000000 -0400
> +++ linux-2.6.18-rc2/kernel/rtmutex.c	2006-07-30 18:07:08.000000000 -0400
>  <at>  <at>  -433,25 +433,26  <at>  <at>  static int task_blocks_on_rt_mutex(struc
>	...
>  	else if (debug_rt_mutex_detect_deadlock(waiter, detect_deadlock)) {
>  		spin_lock_irqsave(&owner->pi_lock, flags);
> -		if (owner->pi_blocked_on) {
> +		if (owner->pi_blocked_on)
>  			boost = 1;
> -			/* gets dropped in rt_mutex_adjust_prio_chain()! */
> -			get_task_struct(owner);
> -		}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pavel Machek | 1 Aug 2006 01:01
Picon

Re: Generic battery interface

Hi!

> frequently it can read from the chip. And no hardware monitoring chip I
> know of can tell when the monitored value has changed - you have to read
> the chip registers to know.

ACPI battery can tell when values change in significant way. (Like
battery becoming critical).

								Pavel
--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 Aug 2006 01:08
Picon
Gravatar

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

On Monday 31 July 2006 20:55, Hua Zhong wrote:
]--snip--[
> > He claims s-t-ram is easier than s-t-disk. That means that he did not do his 
> > homework, and did not check the archives on the subject.
> 
> Oh yeah? Let's check the archives:
> 
> "I seriously claim that STR _should_ be a lot simpler than suspend-to-disk, 
> because it avoids all the memory management problems. The reason that 
> we support suspend-to-disk but not STR is totally perverse - it's simply that
> it has been easier to debug, because unlike STR, we can do a "real boot" 
> into a working system, and thus we don't have the debugging problems that
> the "easy" suspend/resume case has."
> 
> http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=2105

The "_should_" is important here, IMHO.

I think the problems that we have with getting STR to work on many machines
reflect the situation in which we are with respect to the hardware.  From the
programming point of view it's easy, because if you know how to handle the
hardware, it doesn't take a lot to get it right.  Still, you need to _know_,
and we're talking of things that are hardly documented and require hours of
trial-and-error to figure out.  Usually, it can only be done by someone who
(a) has access to the hardware in question, (b) has a lot of time, (c)  is
_very_ determined to make the suspend and resume work on this particular
 device, because these things are notoriously difficult to debug,  and (d),
ideally, knows how to write Linux device drivers.  If you own an "exotic"
notebook, there's practically no chance to find someone like that who owns
one too.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Troin | 1 Aug 2006 01:13

Re: Question about "Not Ready" SCSI error

Patrick Mau <mau <at> oscar.ping.de> writes:

> Hallo everyone
> 
> Today one of my SCSI drives decided to shutdown for no obvious reason.
> I suspect heat or a bad power supply. Syslog shows a repeating stream
> of the following:
> 
> Jul 30 15:51:30 tony kernel: sd 0:0:0:0: Device not ready: <6>: Current: sense key=0x2
> Jul 30 15:51:30 tony kernel: ASC=0x4 ASCQ=0x2
> Jul 30 15:51:30 tony kernel: end_request: I/O error, dev sda, sector 617358
> 
> Google revealed[1] that the drive is waiting for a START UNIT command,
> but it seems that the kernel is not attempting to spin up the drive
> again. 
> 
> After a complete power-cycle the drive worked again. I just wanted to
> know if this is a shortcoming in the SCSI error handling codepath.

I'll have to report that I've seen a few drives behaving similarly,
both on 2.4.x and 2.6.x.

Is that an expected behavior from SCSI hard drives?  Any SCSI guru
would be able to answer this one?

Phil.
Permalink | Reply | 1 comment |
headers
Alan Cox | 1 Aug 2006 01:36
Picon

Re: [PATCH] Kconfig for radio cards to allow VIDEO_V4L1_COMPAT

Ar Llu, 2006-07-31 am 18:28 -0300, ysgrifennodd Mauro Carvalho Chehab:
> > The USB radio is probably the only one that matters, and I do have one
> > of those.
> Are you referring to "D-Link USB FM radio support"? I'll seek some time
> to convert it and ask you to test it. Shouldn't be hard.

Did it today - patches will follow
Permalink | Reply | 0 comments |
headers
Jeff V. Merkey | 1 Aug 2006 01:52

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

Nate Diller wrote:

> On 7/31/06, Jeff V. Merkey <jmerkey <at> wolfmountaingroup.com> wrote:
>
>> Gregory Maxwell wrote:
>>
>> > On 7/31/06, Alan Cox <alan <at> lxorguk.ukuu.org.uk> wrote:
>> >
>> >> Its well accepted that reiserfs3 has some robustness problems in the
>> >> face of physical media errors. The structure of the file system 
>> and the
>> >> tree basis make it very hard to avoid such problems. XFS appears 
>> to have
>> >> managed to achieve both robustness and better data structures.
>> >>
>> >> How reiser4 compares I've no idea.
>> >
>> >
>> > Citation?
>> >
>> > I ask because your clam differs from the only detailed research that
>> > I'm aware of on the subject[1]. In figure 2 of the iron filesystems
>> > paper that Ext3 is show to ignore a great number of data-loss inducing
>> > failure conditions that Reiser3 detects an panics under.
>> >
>> > Are you sure that you aren't commenting on cases where Reiser3 alerts
>> > the user to a critical data condition (via a panic) which leads to a
>> > trouble report while ext3 ignores the problem which suppresses the
>> > trouble report from the user?
>> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 1 Aug 2006 01:20
Favicon

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

Al Boldi wrote:
>>>
>>> Being semantically the same, while not exhibiting ramfs pitfalls, makes
>>> it suitable to be pushed into the -stable tree, IMHO.
>> This is total nonsense.
> 
> Are you sure?
> 

Yes.

>> They're very different from an implementation standpoint.
> 
> Think ext2/3.

Not applicable to this case.

	-hpa
Permalink | Reply | 0 comments |
headers
Nate Diller | 1 Aug 2006 01:21
Picon

Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

On 7/31/06, Matthias Andree <matthias.andree <at> gmx.de> wrote:
> Adrian Ulrich wrote:
>
> > See also: http://spam.workaround.ch/dull/postmark.txt
> >
> > A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
>
> Whatever Postmark does, this looks pretty besides the point.

why's that?  postmark is one of the standard benchmarks...

> Are these actual transactions with the "D"urability guarantee?
> 3000/s doesn't look too much like you're doing synchronous I/O (else
> figures around 70/s perhaps 100/s would be more adequate), and cache
> exercise is rather irrelevant for databases that manage real (=valuable)
> data...

Data:
        204.62 megabytes read (8.53 megabytes per second)
        271.49 megabytes written (11.31 megabytes per second)

looks pretty I/O bound to me, 11.31 MB/s isn't exactly your latest DDR
RAM bandwidth.  as far as the synchronous I/O question, Reiser4 in
this case acts more like a log-based FS.  That allows it to "overlap"
synchronous operations that are being submitted by multiple threads.

NATE
Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 Aug 2006 01:23
Picon
Gravatar

Re: XFS vs. swsusp

Hi,

On Tuesday 01 August 2006 00:53, Pavel Machek wrote:
> > > Rafael has patches to add bdev freezing to swsusp. I'd like to know if
> > > they are neccessary (and why).
> > > 
> > > 1) Is sync() enough to guarantee that all the data written before sync
> > > actually reach the platters?
> > > 
> > > (Or is it that data only reach the journal? OTOH that would be okay, too).
> > 
> > It ensures file data reaches its final resting place, and that
> > metadata changes have been logged.  It does not necessarily
> ....
> 
> Okay, good, being safely in the journal is okay.
> 
> > > 2) If we stop all the user proceses and all the kernel threads, is
> > > that enough to prevent XFS from writing to disk?
> > 
> > Yes, I believe so (if all user processes and kernel threads are
> > stopped, who else would be left to initiate I/O?).  There is a
> 
> Well, we were afraid that you'd do it from timer interrupt or
> something like that.
> 
> > timer driven wakeup done on the per-fs xfssyncd kernel threads,
> > which do background metadata writeout and will write to the log
> > periodically... but if those processes are all stopped too, you
> > should be OK.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane