From: Petr Tesarik <ptesarik@suse.cz>
To: linux-ia64@vger.kernel.org
Subject: RE: [PATCH] Ensure PSR.ac is cleared for early userspace
Date: Tue, 18 Nov 2008 07:06:53 +0000 [thread overview]
Message-ID: <1226992013.32510.10.camel@nathan.suse.cz> (raw)
In-Reply-To: <200811120135.mAC1ZoSd017352@agluck-lia64.sc.intel.com>
Luck, Tony píše v Po 17. 11. 2008 v 12:58 -0800:
> > Ignorance being bliss?
>
> If the module is only hitting unaligned addresses that the processor
> can handle ... then ignorance might well be bliss. The cost of
> an un-reported misaligned access is anly a few cycles. The cost
> of the trap and trip to arch/ia64/kernel/unaligned.c is IIRC
> somewhere in the 800-900 cycle range ... more for the printk.
>
> If we had less of a sledgehammer to report the problem, then I'd
> find it a lot easier to say that this should be enabled in
> production systems.
>
> > If this module was developed in an environment where the unaligned
> > accesses could not be easily seen how does hiding the messages in
> > production get them addressed? Modules being developed in such
> > environments would seem to suggest that the messages _should_ be seen in
> > production?
>
> Definitely a downside to my approach ... if the end users
> don't see that they have been sold a crummy driver they
> won't know that they should complain.
Well, then let's make it a boot option (or a sysctl). The default must
be psr.ac = 1, but if the admin sees "unaligned access" messages and
knows that there is no way of getting a (timely) fix for that particular
production system, s/he should be able to turn them off.
IMO this approach solves both issues, because:
1. Everebody is aware of the performance hit
2. The cost of it can be minimized
Just my two cents,
Petr Tesarik
next prev parent reply other threads:[~2008-11-18 7:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 1:35 [PATCH] Ensure PSR.ac is cleared for early userspace Luck, Tony
2008-11-13 6:22 ` Isaku Yamahata
2008-11-15 1:38 ` Luck, Tony
2008-11-15 3:03 ` David Mosberger-Tang
2008-11-15 19:57 ` Tony Luck
2008-11-17 18:59 ` Rick Jones
2008-11-17 19:45 ` Luck, Tony
2008-11-17 19:52 ` Rick Jones
2008-11-17 20:58 ` Luck, Tony
2008-11-18 7:06 ` Petr Tesarik [this message]
2008-11-18 7:12 ` Matthew Wilcox
2008-11-18 11:58 ` Robin Holt
2008-11-20 22:45 ` Luck, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1226992013.32510.10.camel@nathan.suse.cz \
--to=ptesarik@suse.cz \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.