feel free...
On Fri, Jun 27, 2008 at 8:21 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
> So, who's doing this?
>
>
> On Fri, Jun 27, 2008 at 5:44 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote:
>> I think the easiest short-term fix is just to revert that changeset...
>> the only thing it provides
So, who's doing this?
On Fri, Jun 27, 2008 at 5:44 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote:
> I think the easiest short-term fix is just to revert that changeset...
> the only thing it provides is better error messages, so there's no big
> loss for that. We can resurrect it once we fix the
I think the easiest short-term fix is just to revert that changeset...
the only thing it provides is better error messages, so there's no big
loss for that. We can resurrect it once we fix the memory leak.
Steve
On Fri, Jun 27, 2008 at 5:32 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
>> I thou
> I thought about that and got rid of the ones in CopyString*().
> However, without passing the tc object and creating a new port the
> getfile (m5 op that stucks in the config file) fails to work
> correctly. There must be something more going on there, but I couldn't
> figure out what was happeni
I thought about that and got rid of the ones in CopyString*().
However, without passing the tc object and creating a new port the
getfile (m5 op that stucks in the config file) fails to work
correctly. There must be something more going on there, but I couldn't
figure out what was happening
Bummer... sorry about that. I think it was originally OK but in the
process of working around the issue with N:1 functional ports (recall
our earlier discussion on this) I backed off on deleting ports
aggressively and ended up with this leak.
That said, is there any reason that CopyString*() real
This changeset creates an extraordinarily large memory leak. Every
time getVirtPort(tc) is called a peer seems to be created that is
never deleted. This is particularly problematic since CopyString*()
uses getVirtPort(tc) and so within a minute of executing a kernel with
a lot of dprintk()s
I looked at that changeset (61d9e3f44b40 for those following along at
home) and can't fathom why that got commented out, so I'd say go for
it. You might want to spell-check your commit message though :-).
Probably should put the original changeset ID in the commit message to
for future reference.
# HG changeset patch
# User Ali Saidi <[EMAIL PROTECTED]>
# Date 1214590381 14400
# Node ID 7da118d4638b89018a53c0f6059b9b7e0fc47f99
# Parent d9de38fba64c204f5eb5ea87adb9b9c0c9e9c1c6
It seems that after a checkpoint (and thus a stats reset), the
not_idle_fraction/notIdleFraction statistic is real
* do-regression: qsub timed out, retrying locally
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
***
10 matches
Mail list logo
