On 03/18/2013 01:00 PM, Vivek Goyal wrote:
> On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
>> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>>>
>>> Thinking more about it, if ongoing DMA is an issue, then setting up
>>> software iotlb in those areas is also prone to being overwritten
On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
> >
> > Thinking more about it, if ongoing DMA is an issue, then setting up
> > software iotlb in those areas is also prone to being overwritten by
> > those DMAs. Hence, reserving memory l
On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
>
Agre
On Mon, Mar 18, 2013 at 8:33 AM, Vivek Goyal wrote:
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
On Mon, Mar 18, 2013 at 10:46:03AM -0400, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu wrote:
> > > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
> > >>> No need to use crashkernel_high, we can just cashke
On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
> >>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> >>
> >> crashkernel=X@Y is little different. It a
On Mon, Mar 11, 2013 at 02:06:57PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 02:03 PM, Vivek Goyal wrote:
> >>
> >> And the solution to that isn't obvious?
> >
> > Sorry, I did not understand what do you mean by above.
> >
> > If you are suggesting that move away from dracut, it does not work
* Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> > On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > >
> > > - Now we use dracut generated initramfs and it has been growing in
> > > size. Now systemd has been pulled in too.
> >
> > And the solution to th
On Mon, Mar 11, 2013 at 2:06 PM, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 01:57:41PM -0700, Yinghai Lu wrote:
>> On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal wrote:
>> > In my experience, trying to keep foot-print small has kind of been a
>> > losing battle.
>> >
>> > - People want more funct
On 03/11/2013 02:10 PM, Vivek Goyal wrote:
>
> To me kdump environment requirement should be
> no different.
>
kdump *is* different. Sounds like you need to realize and deal with
that fact.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Mon, Mar 11, 2013 at 01:42:37PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 01:38 PM, Eric W. Biederman wrote:
> >
> > I totally makes sense to figure out how to load a kernel high. I am not
> > convinced kexec on panic is the best use of that ability. I would argue
> > that it might be bett
On 03/11/2013 02:03 PM, Vivek Goyal wrote:
>>
>> And the solution to that isn't obvious?
>
> Sorry, I did not understand what do you mean by above.
>
> If you are suggesting that move away from dracut, it does not work
> in practice. Initially we wrote our custom code to generate custom
> initram
On Mon, Mar 11, 2013 at 01:57:41PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal wrote:
> > In my experience, trying to keep foot-print small has kind of been a
> > losing battle.
> >
> > - People want more functionality in second kernel, want to dump to more
> > compli
On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> >
> > - Now we use dracut generated initramfs and it has been growing in size.
> > Now systemd has been pulled in too.
> >
>
> And the solution to that isn't obvious?
Sorry, I did no
On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal wrote:
> In my experience, trying to keep foot-print small has kind of been a
> losing battle.
>
> - People want more functionality in second kernel, want to dump to more
> complicated IO stacks and that requires pulling in more drivers,
> more libr
On 03/11/2013 01:45 PM, Vivek Goyal wrote:
>
> - Now we use dracut generated initramfs and it has been growing in size.
> Now systemd has been pulled in too.
>
And the solution to that isn't obvious?
> - makdumpfile needs more memory to dump large machines.
>
> There are so many places where
On Mon, Mar 11, 2013 at 01:38:53PM -0700, Eric W. Biederman wrote:
[..]
> I would argue
> that it might be better to figure out how to use a small memory
> foot-print and try to keep that foot-print from growing.
In my experience, trying to keep foot-print small has kind of been a
losing battle.
On 03/11/2013 01:38 PM, Eric W. Biederman wrote:
>
> I totally makes sense to figure out how to load a kernel high. I am not
> convinced kexec on panic is the best use of that ability. I would argue
> that it might be better to figure out how to use a small memory
> foot-print and try to keep th
"H. Peter Anvin" writes:
> On 03/11/2013 01:12 PM, Vivek Goyal wrote:
>>>
>>> Quite frankly the whole design seems to be held together with chewing
>>> gum. At the core, the problem is a tight coupling between kexec-tools
>>> version, kexec-tools options, and kernel command line options that hav
On 03/11/2013 01:19 PM, H. Peter Anvin wrote:
>
> The problem with this argument here is that we are spiraling down the
> drain of increasing user-visible complexity in order to not break
> existing but exotic use cases. We need to stop and reverse this trend.
> I want to make a few observations
On 03/11/2013 01:12 PM, Vivek Goyal wrote:
>>
>> Quite frankly the whole design seems to be held together with chewing
>> gum. At the core, the problem is a tight coupling between kexec-tools
>> version, kexec-tools options, and kernel command line options that have
>> to be combined in very ugly
On Mon, Mar 11, 2013 at 12:59:44PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:22 PM, Vivek Goyal wrote:
> >
> > So always reserving memory at highest address will break all the cases
> > which work without iommu and rely on swiotlb. I think first we need
> > to make sure that kdump works reli
On Mon, Mar 11, 2013 at 12:55:55PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:20 PM, Vivek Goyal wrote:
> >
> > I find it odd that if a user wants to load a 32bit kernel or use 32bit
> > entry point then he needs to first reboot the kernel and re-reserve
> > the memory.
> >
> > At installati
On 03/11/2013 12:22 PM, Vivek Goyal wrote:
>
> So always reserving memory at highest address will break all the cases
> which work without iommu and rely on swiotlb. I think first we need
> to make sure that kdump works reliably with iommu on, and then try
> to move to always reserving memory at h
On 03/11/2013 12:14 PM, Eric W. Biederman wrote:
>
> I don't totally follow the reasoning, but there is one real motivating
> example that is not easy to fix and it has little to do with
> kexec-tools. There is a practical issue that so far the easiest way
> to deal with iommus after a kexec on p
On 03/11/2013 12:20 PM, Vivek Goyal wrote:
>
> I find it odd that if a user wants to load a 32bit kernel or use 32bit
> entry point then he needs to first reboot the kernel and re-reserve
> the memory.
>
> At installation time, one does not necessarily know what kind of kernel
> will be used for
On Mon, Mar 11, 2013 at 12:39:56PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
> >> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> >
> > crashkernel=X@Y is little different. It assumes user knows the memory
> > map and location "Y" is fix
On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
>>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
>>
>> crashkernel=X@Y is little different. It assumes user knows the memory
>> map and location "Y" is fixed. There m
On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
>
> crashkernel=X@Y is little different. It assumes user knows the memory
> map and location "Y" is fixed. There might not be any memory at "Y".
then use crashkernel=4G?
--
On Mon, Mar 11, 2013 at 12:34:00PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:10 PM, Vivek Goyal wrote:
> > Not breaking existing cases makes sense to me.
>
> that is -v2 version:
> try 896M, then try 4G, than MAXMEM.
>
> > May be we should use
> > a new parameter crashkernel_high to
On Mon, Mar 11, 2013 at 12:10 PM, Vivek Goyal wrote:
> Not breaking existing cases makes sense to me.
that is -v2 version:
try 896M, then try 4G, than MAXMEM.
> May be we should use
> a new parameter crashkernel_high to force memory reservation above
> 4G and crashkernel=X continues to reserve m
On Mon, Mar 11, 2013 at 12:14:16PM -0700, Eric W. Biederman wrote:
> "H. Peter Anvin" writes:
>
> > On 03/11/2013 11:50 AM, Yinghai Lu wrote:
> >>>
> >>> What is the purpose of reserving that kind of memory below 896 MB? If
> >>> you have a 32-bit system, it will likely be useless since you are
On Mon, Mar 11, 2013 at 12:06:06PM -0700, Yinghai Lu wrote:
[..]
> > I actually disagree with trying low memory at all. Push kdump as high
> > into the memory range as we can go, if there is a performance penalty it
> > is much better to take it in the kdump kernel.
>
> Agreed, It's better let 6
On Mon, Mar 11, 2013 at 12:04:38PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:02 PM, Vivek Goyal wrote:
> >>
> >> What is the purpose of reserving that kind of memory below 896 MB? If
> >> you have a 32-bit system, it will likely be useless since you are
> >> robbing the primary of most of lo
"H. Peter Anvin" writes:
> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>>
>>> What is the purpose of reserving that kind of memory below 896 MB? If
>>> you have a 32-bit system, it will likely be useless since you are
>>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>>>
On Mon, Mar 11, 2013 at 11:55:52AM -0700, H. Peter Anvin wrote:
> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
> >>
> >> What is the purpose of reserving that kind of memory below 896 MB? If
> >> you have a 32-bit system, it will likely be useless since you are
> >> robbing the primary of most of low
On 03/11/2013 12:06 PM, Yinghai Lu wrote:
>>
>> Are you saying 896M is somehow hardcoded into kexec-tools?
>
> yes, before kexec-tools 2.0.4
>
How old is that?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
On Mon, Mar 11, 2013 at 12:06 PM, H. Peter Anvin wrote:
> On 03/11/2013 12:06 PM, Yinghai Lu wrote:
>>>
>>> Are you saying 896M is somehow hardcoded into kexec-tools?
>>
>> yes, before kexec-tools 2.0.4
>>
>
> How old is that?
2.0.4 is not released yet. and 2.0.4 would support load v3.9 that
supp
On 03/11/2013 12:02 PM, Vivek Goyal wrote:
>>
>> What is the purpose of reserving that kind of memory below 896 MB? If
>> you have a 32-bit system, it will likely be useless since you are
>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>> a magic value in any way...?
>
On Mon, Mar 11, 2013 at 11:55 AM, H. Peter Anvin wrote:
> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>>
>>> What is the purpose of reserving that kind of memory below 896 MB? If
>>> you have a 32-bit system, it will likely be useless since you are
>>> robbing the primary of most of lowmem, on a 6
On Mon, Mar 11, 2013 at 11:46:45AM -0700, H. Peter Anvin wrote:
> On 03/11/2013 11:26 AM, Vivek Goyal wrote:
> >>
> > Hi Yinghai,
> >
> > In mutt your patches are showing as attachment instead of inline. Mutt
> > thinks attachment is of type "application/octet-stream". Not sure if
> > this is conf
On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>
>> What is the purpose of reserving that kind of memory below 896 MB? If
>> you have a 32-bit system, it will likely be useless since you are
>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>> a magic value in any way...?
>
>
On Mon, Mar 11, 2013 at 11:46 AM, H. Peter Anvin wrote:
> On 03/11/2013 11:26 AM, Vivek Goyal wrote:
>>>
>> Hi Yinghai,
>>
>> In mutt your patches are showing as attachment instead of inline. Mutt
>> thinks attachment is of type "application/octet-stream". Not sure if
>> this is configuration issu
On 03/11/2013 11:26 AM, Vivek Goyal wrote:
>>
> Hi Yinghai,
>
> In mutt your patches are showing as attachment instead of inline. Mutt
> thinks attachment is of type "application/octet-stream". Not sure if
> this is configuration issue on my part or something is going on your
> end.
>
> I have fe
On Mon, Mar 11, 2013 at 11:26 AM, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 10:58:39AM -0700, Yinghai Lu wrote:
>> On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal wrote:
>> >
>> > IOW, wouldn't it be better that crashkernel=X first tries to find
>> > requested amount of memory in lowest memory ar
On Mon, Mar 11, 2013 at 10:58:39AM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal wrote:
> >
> > IOW, wouldn't it be better that crashkernel=X first tries to find
> > requested amount of memory in lowest memory area available/possible.
>
> Yest, that is much better, and u
On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal wrote:
>
> IOW, wouldn't it be better that crashkernel=X first tries to find
> requested amount of memory in lowest memory area available/possible.
Yest, that is much better, and user even could stay with old kexec-tools
for system that does not tons o
On Mon, Mar 11, 2013 at 10:48:53AM -0400, Vivek Goyal wrote:
> On Sun, Mar 10, 2013 at 09:56:57PM -0700, Yinghai Lu wrote:
> > Current code does not set low range for crashkernel if the user
> > does not specify that.
> >
> > That cause regressions on system that does not support intel_iommu
> > p
On Sun, Mar 10, 2013 at 09:56:57PM -0700, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.
>
> That cause regressions on system that does not support intel_iommu
> properly.
>
> Chao said that his system does work well on 3.8 without ext
Current code does not set low range for crashkernel if the user
does not specify that.
That cause regressions on system that does not support intel_iommu
properly.
Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.
Set crashkernel_low au
50 matches
Mail list logo
