Just built a new system with Linux-2.4.0.
Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem
fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each
channel of this controller I have an IBM 45 GB ATA100 drive as master.
(hde and hdg?). BIOS sees these
And if anybody else understands pirq routing, speak up. It's a black art.
I have some experience with PIRQ and Serverworks, but I missed the first
bit of this discussion - can someone catch me up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
0x44 and 0x45 are probably ID's of two primary buses and the code should scan
both of them, but not the space between them.
0x44 is the primary bus number of the host bridge, and 0x45 is the
subordinate bus
Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
Your "link" values are
OK to me.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
--- /home/users/admin/C26/III/linux-2.2/drivers/scsi/sym53c8xx.cTue May 15
19:14:48 2001
+++ /usr/src/linux/drivers/scsi/sym53c8xx.c Wed May 16 22:52:12 2001
to that it requires
YACC, when most people have bison (yes, a shell script is easy to make, but
not always an option).
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, but otherwise I'd rather like to use the measuring
code in IDE driver as it requires no user intervention to get the right
timing.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/pci/pci.c cobalt-2.4.5/drivers/pci/pci.c
Attached is a patch for cleaning up some PCI ids and adding a few that were
missing. Please let me know of any problems with this.
(diff against 2.4.5)
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/pci
inclusion.
This patch also includes support for a configurable 'max failures'
parameter, and one change for better DMA error reporting.
Tim
Andre Hedrick wrote:
Bring it on! ;-)
On Tue, 27 Mar 2001, Tim Hockin wrote:
Andre,
I'm doing some work toward hotswap IDE, and I had a query
All,
Attached is a patch for sym53c8xx.c to handle the error timer better, and
be more proper for SMP. The changes are very simple, and have been beaten
on by us. Please let me know if there are any problems accepting this
patch for general inclusion.
Tim
--
Tim Hockin
Systems Software
earlier).
Please let me know if you have any problems with this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
earlier).
Please let me know if you have any problems with this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/ide/hpt366.c cobalt-2.4.5/drivers/ide/hpt366.c
--- dist-2.4.5/drivers/ide
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems
Add a rwproc entry to the ide structure, for recalling what happened last
time!
Please let me knwo if there are any problems with this patch (some of the
patches I sent earlier depend on this).
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL
if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/README cobalt-2.4.5/drivers/cobalt/README
if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/acpi.c cobalt-2.4.5/drivers/cobalt/acpi.c
Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
i2c framework is not
Thanks for all the comments, so far. I'm going to incorporate all the
changes mentioned, and resubmit the questioned patches.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
/algorithms submitted for general inclusion. Once that
is in, I will make cobalt_i2c go away.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
All,
attached is a (small) patch which saves the src address on tcp_accept().
Please let me know if there are any problems taking this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/net
I'm noticing these messages:
mtrr: base(0xd400) is not aligned on a size(0x180) boundary
:many times in dmesg. System is a dual P3-933 on a MSI 694D board (Apollo
Pro 133).
Is it worrisome?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, 15 Jan 2001, Tim Hockin wrote:
Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem
fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each
channel of this controller I have an IBM 45 GB ATA100 drive as master.
(hde and hdg). BIOS sees
From searching Google, I know some sort of driver exists. In July, Adam J.
Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
an NSC driver, but had made some minor modifications.
We're still
I haven't received messages in a few days at least...
-
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/
"THIS CHANGE CAUSED PROBLEMS FOR SOME APPLICATION CODE."
_Which_ applications?
_Why_ did they have a problem? Was this due to a bug or were they
designed to do stuff this way?
I, for one, have an app that relies on syscalls not being restarted:
app goes
use vanilla 2.4.x, you can simply copy drivers/net/starfire.c from the -ac
tree.
I can't use 2.4 kernels ATM because they don't boot (at all) on Cobalt
hardware for some reason - when I've got chance I'll look into it and try
and fix the 2.4 kernels so they work on Cobalt kit, but ATM
The attached patch fixes the MOXA driver properly. Indexing is 0 based, so
rather than adjust the enum, don't subtract 1 from each index. Also use a
for loop for the PCI devices, and up the version number.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
, and is a more
complete implementation of sysmp() than the others..
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hey all,
I just had an eepro/100 S delivered to me. I haven't dug through specs
yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to
the core.
Any way we can use it?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED
nvram_open_cnt SMP
safe, or should it just go away all together. I vote for the latter
option, unless something depends on this behavior (in which case, other
fixes are needed, because it is broken :).
comments?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL
Is it possible to bind a process to a specific
cpu on this SMP machine (process affinity) ?
I there something like pset ?
http://isunix.it.ilstu.edu/~thockin/pset - pset for linux-2.2 (not ported
to 2.4 yet)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
when pages have to be freed (I think also when the bdflush writes back
data, i.e. every 30 seconds by default).
what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ?
-
To unsubscribe from this list:
All,
is it possible to detect whether a device is running at 66MHz (as opposed
to 33)? PCI defines a 66MHz capable bit, but not a 66MHz enabled bit. We
have a silly device that seems to need to know what it's bus speed is, but
have no way to tell from software (that I know of).
So, pray tell
disallowed CPU on which it is already running. And even a non-RT
process will stick on its disallowed CPU as long as nothing else runs
there.
are we going to keep the cpus_allowed API? If we want the (IMHO) more
flexible sysmp() API - I'll finish the 2.4 port. If we are going to keep
From: Tim Hockin [EMAIL PROTECTED]
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
On 27 Apr 2007 11:09:17 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
Description:
This patch makes the MCE poller adjust the polling interval dynamically.
If we find an MCE, poll 2x faster (down to 10 ms). When we stop finding
On 27 Apr 2007 19:02:30 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, Apr 27, 2007 at 09:58:14AM -0700, Tim Hockin wrote:
On 27 Apr 2007 11:09:17 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
Description:
This patch makes
From: Tim Hockin [EMAIL PROTECTED]
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
From: Tim Hockin [EMAIL PROTECTED]
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
Sorry, Gmail mangles whitespace unless you do just the right thing.
Let me work around it. Proper patch coming.
On 4/27/07, Tim Hockin [EMAIL PROTECTED] wrote:
From: Tim Hockin [EMAIL PROTECTED]
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially
From: Tim Hockin [EMAIL PROTECTED]
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
some situations. Calling poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user
] mcheck_check_cpu+0x0/0x40
[80214bd4] smp_local_timer_interrupt+0x34/0x60
[8021538e] smp_apic_timer_interrupt+0x4e/0x70
[8020a436] apic_timer_interrupt+0x66/0x70
On 4/29/07, Tim Hockin [EMAIL PROTECTED] wrote:
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog
On 4/13/05, Dave Jones [EMAIL PROTECTED] wrote:
If we have a situation where we screw a subset of users with the
config option =y and a different subset with =n, how is this improving
the situation any over what we have today ?
Dave,
What's a good alternative? Do we need to keep a whitelist
On Mon, Jan 31, 2005 at 01:55:59PM -0500, Mike Waychison wrote:
FWIW, some of the old cobalt boxes had the old south bridge revision
with a WDT. It managed to do resets/wdt off gpio pin 5 though, and
there is a patch in Alan's 2.6.10-ac tree that handles it.
The old Cobalts also had a PIC
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock':
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared
(first use in this function)
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier
is reported only once
A year later - what ever happened with this? I want it more than ever
for Google's use.
On Tue, Jan 31, 2012 at 7:37 PM, Frederic Weisbecker fweis...@gmail.com wrote:
Hi,
Changes In this version:
- Split 32/64 bits version of res_counter_write_u64() [1/10]
Courtesy of Kirill A. Shutemov
On Mon, Apr 1, 2013 at 11:46 AM, Tejun Heo t...@kernel.org wrote:
On Mon, Apr 01, 2013 at 11:43:03AM -0700, Tim Hockin wrote:
A year later - what ever happened with this? I want it more than ever
for Google's use.
I think the conclusion was use kmemcg instead.
Pardon my ignorance
On Mon, Apr 1, 2013 at 1:29 PM, Tejun Heo t...@kernel.org wrote:
On Mon, Apr 01, 2013 at 01:09:09PM -0700, Tim Hockin wrote:
Pardon my ignorance, but... what? Use kernel memory limits as a proxy
for process/thread counts? That sounds terrible - I hope I am
Well, the argument
On Mon, Apr 1, 2013 at 3:03 PM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Mon, Apr 01, 2013 at 02:02:06PM -0700, Tim Hockin wrote:
We run dozens of jobs from dozens users on a single machine. We
regularly experience users who leak threads, running into the tens of
thousands. We
On Mon, Apr 1, 2013 at 3:35 PM, Tejun Heo t...@kernel.org wrote:
Hey,
On Mon, Apr 01, 2013 at 03:20:47PM -0700, Tim Hockin wrote:
U so that's why you guys can't use kernel memory limit? :(
Because it is completely non-obvious how to map between the two in a
way that is safe across
On Mon, Apr 1, 2013 at 4:18 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Mon, Apr 01, 2013 at 03:57:46PM -0700, Tim Hockin wrote:
I am not limited by kernel memory, I am limited by PIDs, and I need to
be able to manage them. memory.kmem.usage_in_bytes seems to be far
too noisy
On Sun, Aug 07, 2005 at 01:36:01PM +0200, Andi Kleen wrote:
Erick Turnquist [EMAIL PROTECTED] writes:
Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
getting nasty messages like these in my dmesg:
On Sun, Aug 07, 2005 at 02:46:50PM -0400, Erick Turnquist wrote:
Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
level.
I don't see anything about SMM in my BIOS configuration even with the
advanced options enabled... Turning it off at the chipset level sounds
like
On Sun, Aug 07, 2005 at 02:51:19PM -0400, Lee Revell wrote:
It's most likely bad SMM code in the BIOS that blocks the CPU too long
and is triggered in idle. You can verify that by using idle=poll
(not recommended for production, just for testing) and see if it goes away.
WTF, since
On Mon, Aug 08, 2005 at 02:01:25PM +0200, Andi Kleen wrote:
Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
level.
Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
for the deeper C* sleep states.
Really? I'm not too familiar with the deeper
4 days ago I had Ubuntu Lucid running on this computer. Suspend and
resume worked flawlessly every time.
Then I upgraded to Ubuntu Precise. Suspend seems to work, but resume
fails every time. The video never initializes. By the flashing
keyboard lights, I guess it's a kernel panic. It fails from
, 2012 12:03:13 PM Tim Hockin wrote:
4 days ago I had Ubuntu Lucid running on this computer. Suspend and
resume worked flawlessly every time.
Then I upgraded to Ubuntu Precise.
Well, do you use a distro kernel or a kernel.org kernel?
Suspend seems to work, but resume
fails every time. The video
, anyway.
It did not require 'noapic' on the Lucid (2.6.32?) kernel
On Sat, Dec 29, 2012 at 9:34 PM, Tim Hockin thoc...@hockin.org wrote:
Running a suspend with pm_trace set, I get:
aer :00:03.0:pcie02: hash matches
I don't know what magic might be needed here, though.
I guess next step
, to see if I
can make it progress.
On Sat, Dec 29, 2012 at 10:19 PM, Tim Hockin thoc...@hockin.org wrote:
Quick update: booting with 'noapic' on the commandline seems to make
it resume successfully.
The main dmesg diffs, other than the obvious Skipping IOAPIC probe
and IRG number diffs
On Sun, Dec 30, 2012 at 2:55 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, December 29, 2012 11:17:11 PM Tim Hockin wrote:
Best guess:
With 'noapic', I see the irq 5: nobody cared message on resume,
along with 1 IRQ5 counts in /proc/interrupts (the devices claiming
that IRQ
On 7/12/07, Andi Kleen [EMAIL PROTECTED] wrote:
-- there may be other edge cases other than
this one. I'm actually surprised that this wasn't a ring buffer to start
with -- it certainly seems like it wanted to be one.
The problem with a ring buffer is that it would lose old entries; but
for
There were other patches which added more COBALT support, but they
were dropped or lost or whatever.
I would not balk at having that code yanked. I never got around to
doing proper Cobalt support for modern kernels. :(
On 6/3/07, Roland Dreier [EMAIL PROTECTED] wrote:
there is no
I think the nvram is the only place left that uses CONFIG_COBALT
On 6/3/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
On Sun, 3 Jun 2007, Tim Hockin wrote:
There were other patches which added more COBALT support, but they
were dropped or lost or whatever.
I would not balk at having
That sounds correct.
On 6/3/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
On Sun, 3 Jun 2007, Tim Hockin wrote:
I think the nvram is the only place left that uses CONFIG_COBALT
sure, but once you remove this snippet near the top of
drivers/char/nvram.c:
...
# if defined(CONFIG_COBALT
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is a clear-on-read interface. It is currently possible for
multiple users to open and read() the device. Users are protected from
each other during any one read, but not across reads.
Description:
This patch adds support for O_EXCL
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog
From: Tim Hockin [EMAIL PROTECTED]
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes
From: Tim Hockin [EMAIL PROTECTED]
Background:
The MCE handler already has an idle-task handler which checks for the
TIF_MCE_NOTIFY flag. Given that the system is idle at that point, we can
get even better granularity of MCE logging by polling for MCEs whenever
we enter the idle loop
On 5/18/07, Andi Kleen [EMAIL PROTECTED] wrote:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
Why? It is not PCC. We cannot return of course, but killing isn't returning.
My understanding is that the absence of RIPV
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is a clear-on-read interface. It is currently possible for
multiple users to open and read() the device. Users are protected from
each other during any one read, but not across reads.
Description:
This patch adds support for O_EXCL
On 5/1/07, Rafal Bilski [EMAIL PROTECTED] wrote:
2.6.21.1 is first kernel which I'm using at this device. Earlier it was
WindowsCE terminal. It is hardware fault. Commenting out the code is my
way to avoid wakeup messages in log, but I don't want to change anything
in vanilla kernel. I'm lucky
On 5/2/07, Rafal Bilski [EMAIL PROTECTED] wrote:
What about module option?
Looks ok to me, if this is the preferred route.
---
drivers/net/natsemi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index
Newer version coming in a while. Testing.
On 4/30/07, Tim Hockin [EMAIL PROTECTED] wrote:
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll
From: Tim Hockin [EMAIL PROTECTED]
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog
In some sense a cgroup is a pgrp that mere mortals can't escape. Why
not just do something like that? root can set this container id or
job id on your process when it first starts (e.g. docker sets it on
your container process) or even make a cgroup that sets this for all
processes in that
I don't buy that it is not practical. Not convenient, maybe. Not
clean, sure. But it is practical - it uses mechanisms that exist on
all kernels today. That is a win, to me.
On Thu, Mar 13, 2014 at 10:58 AM, Simo Sorce sso...@redhat.com wrote:
On Thu, 2014-03-13 at 10:55 -0700, Andy
us REAL pain.
On Mon, Apr 22, 2013 at 3:33 PM, Tim Hockin thoc...@hockin.org wrote:
On Mon, Apr 22, 2013 at 11:41 PM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hockin wrote:
We absolutely depend on the ability to split cgroup hierarchies
On Mon, Jun 24, 2013 at 5:01 PM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Sat, Jun 22, 2013 at 04:13:41PM -0700, Tim Hockin wrote:
I'm very sorry I let this fall off my plate. I was pointed at a
systemd-devel message indicating that this is done. Is it so? It
It's progressing
On Wed, Jun 26, 2013 at 2:20 PM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
I really want to understand why this is SO IMPORTANT that you have to
break userspace compatibility? I mean, isn't Linux supposed to be the
OS
On Wed, Jun 26, 2013 at 6:04 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Wed, Jun 26, 2013 at 05:06:02PM -0700, Tim Hockin wrote:
The first assertion, as I understood, was that (eventually) cgroupfs
will not allow split hierarchies - that unified hierarchy would be the
only mode
Hi Tejun,
This email worries me. A lot. It sounds very much like retrograde
motion from our (Google's) point of view.
We absolutely depend on the ability to split cgroup hierarchies. It
pretty much saved our fleet from imploding, in a way that a unified
hierarchy just could not do. A
On Mon, Apr 22, 2013 at 11:41 PM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hockin wrote:
We absolutely depend on the ability to split cgroup hierarchies. It
pretty much saved our fleet from imploding, in a way that a unified
hierarchy just
The immediate problem I see with setting aside reserves off the top
is that we don't really know a priori how much memory the kernel
itself is going to use, which could still land us in an overcommitted
state.
In other words, if I have your 128 MB machine, and I set aside 8 MB
for OOM handling,
. Replying from my phone is awkward at best. I know better :)
On Wed, Dec 11, 2013 at 09:37:46PM -0800, Tim Hockin wrote:
The immediate problem I see with setting aside reserves off the top
is that we don't really know a priori how much memory the kernel
itself is going to use, which could still land
On Thu, Dec 12, 2013 at 11:23 AM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Thu, Dec 12, 2013 at 10:42:20AM -0800, Tim Hockin wrote:
Yeah sorry. Replying from my phone is awkward at best. I know better :)
Heh, sorry about being bitchy. :)
In my mind, the ONLY point of pulling
On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Mike Galbraith (bitbuc...@online.de):
On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
Hello, Tim.
On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
I really want to understand why
Changing the subject, so as not to mix two discussions
On Thu, Jun 27, 2013 at 9:18 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
FWIW, the code is too embarassing yet to see daylight, but I'm playing
with a very lowlevel cgroup manager which supports nesting itself.
Access in this POC
On Thu, Jun 27, 2013 at 11:11 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Tim Hockin (thoc...@hockin.org):
For our use case this is a huge problem. We have people who access
cgroup files in a fairly tight loops, polling for information. We
have literally hundeds of jobs running
On Thu, Jun 27, 2013 at 10:38 AM, Tejun Heo t...@kernel.org wrote:
Hello, Tim.
On Wed, Jun 26, 2013 at 08:42:21PM -0700, Tim Hockin wrote:
OK, then what I don't know is what is the new interface? A new cgroupfs?
It's gonna be a new mount option for cgroupfs.
DTF and CPU and cpuset all
On Thu, Jun 27, 2013 at 11:14 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Tejun Heo (t...@kernel.org):
Hello, Serge.
On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
At some point (probably soon) we might want to talk about a standard API
for these things. However
On Fri, Jun 28, 2013 at 9:31 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Tim Hockin (thoc...@hockin.org):
On Thu, Jun 27, 2013 at 11:11 AM, Serge Hallyn serge.hal...@ubuntu.com
wrote:
Quoting Tim Hockin (thoc...@hockin.org):
For our use case this is a huge problem. We have
On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote:
So what you're saying is that you don't care that this new thing is
less capable than the old thing, despite it having real impact.
Sort of. I'm saying
On Fri, Jun 28, 2013 at 8:53 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Daniel P. Berrange (berra...@redhat.com):
Are you also planning to actually write a new cgroup parent manager
daemon too ? Currently my plan for libvirt is to just talk directly
I'm toying with the idea,
On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 27-06-13 22:01:38, Tejun Heo wrote:
Oh, that in itself is not bad. I mean, if you're root, it's pretty
easy to play with and that part is fine. But combined with the
hierarchical nature of cgroup and file
On Fri, Jun 28, 2013 at 12:21 PM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Tim Hockin (thoc...@hockin.org):
On Fri, Jun 28, 2013 at 9:31 AM, Serge Hallyn serge.hal...@ubuntu.com
wrote:
Quoting Tim Hockin (thoc...@hockin.org):
On Thu, Jun 27, 2013 at 11:11 AM, Serge Hallyn
Come on, now, Lennart. You put a lot of words in my mouth.
On Fri, Jun 28, 2013 at 6:48 PM, Lennart Poettering lpoet...@redhat.com wrote:
On 28.06.2013 20:53, Tim Hockin wrote:
a single-agent, we should make a kick-ass implementation that is
flexible and scalable, and full-featured enough
On Sun, Jun 30, 2013 at 12:39 PM, Lennart Poettering
lpoet...@redhat.com wrote:
Heya,
On 29.06.2013 05:05, Tim Hockin wrote:
Come on, now, Lennart. You put a lot of words in my mouth.
I for sure am not going to make the PID 1 a client of another daemon.
That's
just wrong. If you have
How is this different from RLIMIT_AS? You specifically mentioned it
earlier but you don't explain how this is different.
From my perspective, this is pointless. There's plenty of perfectly
correct software that mmaps files without concern for VSIZE, because
they never fault most of those pages
1 - 100 of 222 matches
Mail list logo
